New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRAILS-7232: Refine the stack sanitization and improve the output readability of regular traces #3856

Closed
graemerocher opened this Issue Feb 7, 2011 · 7 comments

Comments

Projects
None yet
1 participant
@graemerocher
Member

graemerocher commented Feb 7, 2011

Original Reporter: wangjammer5
Environment: Not Specified
Version: 1.3.6
Migrated From: http://jira.grails.org/browse/GRAILS-7232

I mentioned the idea to alter the output of stack traces on the list, and it was enthusiastically received.

Basically we'd either need to replace the printStackTrace impl or call our own stack dumper method whenever we dump traces. This may be non-trivial, but the gains will be significant.

Key requirements:

  • Make it trivial for people to see the deepest point of the trace - the point of failure
  • Hide groovy internals
  • Make it easier for humans who are not Java gurus to scan
  • Reduce duplication

Example desired output:

{code}
=============== GRAILS EXCEPTION ===================
Cannot get property 'userName' on null object (java.lang.NullPointerException)
doCall method on line 217 in NoticeUtilsService.groovy (NoticeUtilsService$_processResults_closure5_closure7)

Stack trace:

Line | Method
->> 217 | doCall in NoticeUtilsService.groovy
| | - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 216 | doCall in " "
| 214 | processResults in " "
| 129 | mapFields in KnownUserService.groovy
| 97 | sendMessage in NoticeEventsService.groovy
| 58 | noticeEvent in " "
| 199 | doCall in BoardAreaController.groovy
| 167 | doArchiveRestore in " "
| 127 | doCall in " "
^ 680 | run in Thread.java (java.lang)

See your unsanitized stack log for the full Java stack trace if necessary.
{code}

The detail is important here:

  • It needs to calculate column widths for line number and method, and align all text correctly
  • The arrows and separator are important visual cues
  • The source file is shown in the stack trace lines, NOT the class name. the package name is included in brackets, no brackets shown at all if code is in the default package
  • We need to filter out code with no source (Unknown Source)
  • We need configurable sanitized packages, so users can add stuff to Config - or preferably they can specify the list of package prefixes that are in their app, in Config: grails.stack.packages=['org.myapp']
  • Class names are in general not shown except in the first couple of lines of preamble.
@graemerocher

This comment has been minimized.

Member

graemerocher commented Feb 7, 2011

wangjammer5 said:
The above could also use "@" instead of "in"

@graemerocher

This comment has been minimized.

Member

graemerocher commented Feb 7, 2011

brownj said:
Does the "in" column really add anything to readability?

@graemerocher

This comment has been minimized.

Member

graemerocher commented Feb 7, 2011

wangjammer5 said:
I think in or @ is fine, but I think its important line number is before file name, with a meaningful separator...

@graemerocher

This comment has been minimized.

Member

graemerocher commented Feb 24, 2011

david_beutel said:
I like the line number column next to the source file column.

@graemerocher

This comment has been minimized.

Member

graemerocher commented Feb 24, 2011

pledbrook said:
This feature probably needs some way for IDEs to force output to the old format, since that's the format they are used to processing.

@graemerocher

This comment has been minimized.

Member

graemerocher commented Jun 14, 2011

graemerocher said:
old output can be reactivated with "grails -verbose"

@graemerocher

This comment has been minimized.

Member

graemerocher commented Jun 27, 2011

graemerocher said:
Can you attach an example and I'll take a look? It should recursively show nested exceptions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment