Configurable Exception StackTraces

[thomasdarimont]

Java Applications are famous for their loooooong exception strack-trace dumps that is really cumbersome to work with - for beginners and experts alike.

It would be cool if spring-boot-dev-tools could do something about it to make it easier to see the actual location of a problem in the code represented by an exception.

Some ideas based on a quick twitter discussion about what could be done are:

1. Filter out StackTraceElements (STEs) via patterns

More often than not your problem is probably not in sun.* or in the inner workings of the Spring Container or a Proxy...

2. Pattern match and collapse mutiple STEs

Pattern match and collapse mutiple STEs into one line with a "higher level message"
E.g.: "Spring Security Filter Processing", "Spring MVC Handler Processing", "Java Reflective Method Invocation"

3. Combine multiple STEs into one line

E.g. in the form org.comp.my.package[Type1:32, Type2:222, Type3:212] by leaving out the method names the line number is often could still help to jump.

4. Use ansi coloring to fade "unimportant" STEs

This would draw the attention to the "intersting" bits - but users would still have to scroll ...

5. Repeat the root cause on the last line

By printing the actuall error message and perhaps the last 2,3 Stack Frames your quickly allow users to quickly jump to the actual problem.

Of course it is probably often hard to judge what (not) to show when but I think being able to quickly see the actual problem in most of the cases would pay off. Perhaps it is possible to dynamically decide whether or not a particular STE is "important" or not...

[jeanbza]

+1

edit: esp 1, 4

[philwebb]

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.

[philwebb]

We'll raise a new issue for exception hiding.