Groovy stacktrace folding
March 17th, 2010 by Peter GromovWhen you look at a typical Groovy stack trace, you usually see something like this:
This is not terribly helpful, since there are only three lines from the actual source code. Everything else refers to Groovy’s internals. From now on, though, reading Groovy stack traces will be much easier:



March 17th, 2010 at 6:30 am
Thanks a lot for that. Groovy stacktraces are no fun without that.
March 17th, 2010 at 7:14 am
Great new feature!
Any thoughts about doing it for Spring based (AOP) applications?
When running Spring AOP applications, the stack trace is full of aspect wrappers and proxies that pollute the stack trace and makes reading it a pain.
March 17th, 2010 at 9:59 am
Very nice! Good idea!
Perhaps you could also filter the org.jetbrains.* lines as well?
March 17th, 2010 at 10:16 am
Guillaume,
No. It was a stack trace precisely from the IDEA project, so it’s definitely the code I’d like to see when developing IDEA. And I don’t know of any place when the org.jetbrains.* stuff really gets in the way. Do you?
March 17th, 2010 at 10:35 am
Very nice. How do you decide whether a line should be displayed (or not)?
March 17th, 2010 at 10:39 am
Now it’s just hardcoded, and it’s all Java reflection, org.codehaus.groovy.* and groovy.* (except for DefaultGroovyMethods). It should probably be configurable, though I don’t yet imagine a UI for it.
March 17th, 2010 at 1:36 pm
This is brilliant!
A UI to configure this would be nice (like YourKit Java Profiler has).
I would love to be able to filter other stuff as well, like Spring and Struts.
March 17th, 2010 at 5:21 pm
Looks nice. I’d love to see something like this for La Clojure too. Clojure stack traces are even uglier than groovy.
March 17th, 2010 at 8:33 pm
Love the idea. If you were to develop a UI, I think it would be nice to have a whitelist as well as a blacklist for folding.
For instance, maybe I’m only interested in:
com.acme.*
org.hibernate.*
org.springframework.*
And the rest is folded.
March 18th, 2010 at 1:41 am
Peter, the UI for which packages to filter can be the exact same list as which packages to _not_ step into. The settings panel already has this list. I opened a bug for exactly this a few months ago.
Great improvement gang, thanks!
March 18th, 2010 at 3:00 am
Hamlet, not exactly. The current not-to-step-into-list doesn’t allow to step into DefaultGroovyMethods while not stepping to everything else in groovy.*. While I’m not so sure whether I need to step into that code, I definitely want to see it in the stack traces.
The idea of combining the two lists is very attractive, although maybe too dare, but the stepping filters are actually a JVM feature and have a very restricted format, which AFAIK doesn’t allow for exclusions like DGM. It also doesn’t support filtering for specific methods in the class, (e.g. in the java.lang.reflect.Method we filter out only the invoke() method). So, it’s not that simple.
March 18th, 2010 at 3:31 am
Very nice. I would love to see this feature in “normal” Java code, too. For example a button in the run console that filters out all stack trace lines referring to classes from external libraries.
March 18th, 2010 at 4:20 am
This could be usefull in spring stacktraces too: to hide all the AOP proxy and reflection stuff under a + sign.
April 22nd, 2010 at 12:22 pm
+1 for Geoffrey’s suggestion on filtering the AOP/Proxy reflection stacktraces listed by Spring. Great idea!
April 23rd, 2010 at 9:03 am
+1 to AOP filtering
+1 to user configurable via UI
May 7th, 2010 at 2:10 am
To everyone who asked. ConsoleFolding plugin with configuration UI available at http://plugins.intellij.net/plugin/?idea&id=4975
May 19th, 2010 at 6:38 am
Nice feature.
+1 to user configurable via UI
I could include then …
org.jboss.el.util.ReflectionUtil.* (or org.jboss.el.util.ReflectionUtil.invokeMethod)
com.intellij.rt.execution.application.AppMain.main
August 2nd, 2010 at 7:09 pm
Why doesnt Groovy just edit its own stack traces?
java.lang.Throwable {
public java.lang.StackTraceElement[] getStackTrace();
public void setStackTrace(java.lang.StackTraceElement[]);
}
August 3rd, 2010 at 3:00 am
Laird,
Actually, it sort of does. If you run a script and there’s an exception, all the lines which correspond to *.java code will be removed. I guess the assumption was that the only Java code executed in a Groovy program is Groovy internals, which is often not true.