Description
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...