Offer an option to hide some internal elements of a stacktrace

[snicoll]

We had this feedback

Stack Trace often does not include our code
One of the first things to do when debugging problems is look for the code written by your team in the stack trace. Unfortunately, the exceptions we’re seeing often do not include our code, but instead some higher level abstraction. Maybe this is something that we’ll become familiar with over time, but at the beginning is a source of confusion.

Maybe we could offer a way to rewrite stacktraces such as proxy and interceptors of well-know internal infrastructure code is remove (or compacted).

[wilkinsona]

#3026 describes a related problem

[philwebb]

I personally prefer a too much information rather than too little. Getting rid of duplicate messages (as described in #3026) seems like a sensible approach but I'm not so keen on rewriting existing stacktraces to remove detail.

[snicoll]

That's definitely something to use in development only and could be useful for beginners. But I am ok to close this if there is a consensus that we shouldn't do it.

[wilkinsona]

This is a duplicate of #4451 which was closed with the following reasons:

We've discussed some options for this and we think the best approach is for Spring Boot to try and present less irrelevant exception entirely, and for the other options the IDE is better placed to fold and hide exception messages.

One example that we discussed is the "port in use" exception. For a port clash, the exception is pretty much useless. You don't really care that the guts of Tomcat failed, you only care about the fact that a port is already in use.

So I'm going to close this too. Failure analyzers are our solution for showing fewer irrelevant exceptions, such as when a port clash occurs.