On 2009.12.01., at 8:32, Kjetil Valstadsve wrote: > On 2009-12-01, at 5:00 , Neal Gafter wrote: > >> On Wed, Nov 25, 2009 at 4:31 AM, Jochen Theodorou <[email protected]> wrote: >> Wouldn't it be possible to give an method an attribute so it will no add >> that stack frame to the exception? Is there a problem for the VM to do that? >> >> The .NET platform uses this solution. You put an attribute (the equivalent >> to a Java annotation) on the methods that you don't want to appear in the >> stack trace, and the VM does the rest. > > May I humbly (and maybe somewhat panickedly) suggest retaining an option to > override such an annotation? Given some developers' reluctance to volunteer > error information already, I dread giving them the tools to suppress and > throw out what's already there, in the name of misunderstood information > hiding. > > I realize this is meant for all the "infrastructure" layers (of which Groovy > is one), giving focus to the business logic and nicing up the user-petrifying > stacktraces you get when e.g. multiple layers of dynamic proxies are > involved. But this assumes that the error is never in THAT part, which may > only be true after considerable maturing of the code. > > Anyway, today we have a of getting out the full stacktrace programmatically, > so it can be preserved in full when that makes sense. I just want to point > out the real need for keeping that as it is. Everyone probably agrees, but - > just in case. In the meantime, hacking a nice, custom stacktrace display > using said functionality isn't really that hard, either.
I would agree - I've been involved in pretty-printing stack traces in two of my projects; in the previous post, I mentioned Rhino and how its exceptions interweave JS and Java stack frames. A different approach we took with FreeMarker is that the exceptions first print an error message in plain English and a stack trace in terms of the native programming language (FreeMarker Template Language in this case), and below it, visually distinguished, the Java stack trace, in case the developer wishes to check it. We make it explicit that the topmost information - FreeMarker stack trace - is more useful to template developers, and the bottom information - Java stack trace - is advanced info that might be more useful to Java developers. So far, people seem to really like the format. Examples are abundant on the web as FreeMarker is quite widely used, here's one I found through googling for "Java backtrace for programmers" @ <http://www.ambraproject.org/trac/ticket/1275>. You can see how FreeMarker provides a logical trace through only those elements that are actually helpful in locating the bug: includes and macro/function invocations: 2009-04-28 12:20:04,196 ERROR runtime(PLoSONE)> [http-8080-Processor24 freemarker.runtime] Expression currentIssue is undefined on line 31, column 26 in journals/plosone/article/browseVolume.ftl. The problematic instruction: ---------- ==> ${currentIssue.id} [on line 31, column 24 in journals/plosone/article/browseVolume.ftl] in user-directive s.url [on line 30, column 9 in journals/plosone/article/browseVolume.ftl] in include "${templateFile}" [on line 31, column 1 in templates/main_template.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression currentIssue is undefined on line 31, column 26 in journals/plosone/article/browseVolume.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:134) ... Attila. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
