Groovy stacktrace folding

When 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:

This entry was posted in New Features and tagged , , . Bookmark the permalink.

19 Responses to Groovy stacktrace folding

  1. Stefan A. says:

    Thanks a lot for that. Groovy stacktraces are no fun without that.

  2. Yarin says:

    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.

  3. Very nice! Good idea!
    Perhaps you could also filter the org.jetbrains.* lines as well?

  4. Peter Gromov says:

    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?

  5. Very nice. How do you decide whether a line should be displayed (or not)?

  6. Peter Gromov says:

    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.

  7. Ronny Løvtangen says:

    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.

  8. Glen says:

    Looks nice. I’d love to see something like this for La Clojure too. Clojure stack traces are even uglier than groovy.

  9. Mike Cantrell says:

    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.

  10. 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!

  11. Peter Gromov says:

    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.

  12. Stephan Anft says:

    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.

  13. Geoffrey De Smet says:

    This could be usefull in spring stacktraces too: to hide all the AOP proxy and reflection stuff under a + sign.

  14. Jim Bethancourt says:

    +1 for Geoffrey’s suggestion on filtering the AOP/Proxy reflection stacktraces listed by Spring. Great idea!

  15. Dan Sheehan says:

    +1 to AOP filtering
    +1 to user configurable via UI

  16. Peter Gromov says:

    To everyone who asked. ConsoleFolding plugin with configuration UI available at http://plugins.intellij.net/plugin/?idea&id=4975

  17. Juan Hernandez says:

    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

  18. Laird Dornin says:

    Why doesnt Groovy just edit its own stack traces?

    java.lang.Throwable {
    public java.lang.StackTraceElement[] getStackTrace();
    public void setStackTrace(java.lang.StackTraceElement[]);
    }

  19. Peter Gromov says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>