tag:blogger.com,1999:blog-23881856886969249.post4637418314459060285..comments2024-01-12T16:27:17.222-06:00Comments on Josh (Formerly) In Antarctica: Are Groovy Stacktraces a Showstopper?Josh Reedhttp://www.blogger.com/profile/02066492903706506905noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-23881856886969249.post-17737372522057956102009-08-24T21:46:40.119-05:002009-08-24T21:46:40.119-05:00The example code about the sanitizer used StackTra...The example code about the sanitizer used StackTraceUtils.sanitize. I use "deepSanitize" does that make a difference?<br /><br />I've found that deepSanitize generally gives me fairly good stack traces, except for postgres stuff in there. <br /><br />Of course, it's a pain to use that, but I do'nt find it too terribly bad.Unknownhttps://www.blogger.com/profile/06521462820517167511noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-64936260417887065082009-08-19T18:40:22.096-05:002009-08-19T18:40:22.096-05:00Scott: Default behavior should be the behavior mos...Scott: Default behavior should be the behavior most people want. In this case, I think most people want only the relevant information in the stack trace. So the default should be to only show the relevant information in the stack trace.<br /><br />I never said anything about productivity. Just about expecting people to make configuration changes to shorten/clean stack traces down to what most people actually want. If most people want them to be cleaner/shorter, make them cleaner/shorter by default.Charles Oliver Nutterhttps://www.blogger.com/profile/01770148973571270871noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-33314242150623721712009-08-18T17:29:52.392-05:002009-08-18T17:29:52.392-05:00re Charles Nutter's trolling comment "asi...re Charles Nutter's trolling comment "asinine":<br /><br />The Groovy stacktraces might not be perfect but no one is "forcing users to use the right tool or configure a logging framework" to be productive.<br /><br />My project team for three years consisted of VB/Cobol turned Java newbies and Excel/Foxpro programmers. Somehow, they managed to be incredibly successful using Groovy and had managed to find the first line in the stack trace that pointed to a Groovy file with little trouble. <br /><br />If they could handle it, I would thing professional Java programmers can manage without any tools or cleanup.<br /><br />Would some options for more/less verbosity been useful? Sure. But it needs to be put into perspective. Once your using Groovy on a project, its just not that big of a deal or to the point of the blog: Its just not a showstopper.Scott Hickeyhttps://www.blogger.com/profile/14246732924788969410noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-72685020957382574312009-08-18T16:39:36.209-05:002009-08-18T16:39:36.209-05:00JRuby's stack traces are short because they...JRuby's stack traces are short because they're Ruby traces, not JVM traces. Groovy has no "Groovy traces".<br /><br />Groovy's traces are also long because Groovy has a *lot* more work happening between calls than JRuby does for most things. For Ruby-to-Ruby calls, JRuby will only have 2-4 intermediate frames in the trace, where Groovy will have 10-20 intermediate frames. JRuby does not use reflection for any core classes, which shortens things further. And when calling out to Java, the trace only grows by the size of reflection logic.<br /><br />We've done a lot to make sure stack traces are tight and clean in JRuby. I think "tight and clean" should be the default, not forcing users to use the right tool or configure a logging framework. That's asinine.Charles Oliver Nutterhttps://www.blogger.com/profile/01770148973571270871noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-5640728739418019592009-08-17T20:54:23.073-05:002009-08-17T20:54:23.073-05:00@Anonymous yeah, no sh*t. yours is the best commen...@Anonymous yeah, no sh*t. yours is the best comment here. totally agree.Hamlet D'Arcyhttps://www.blogger.com/profile/04008870357169725586noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-21698107762604748472009-08-17T17:17:09.889-05:002009-08-17T17:17:09.889-05:00First. Welcome to the JVM.
Now if you want succi...First. Welcome to the JVM. <br /><br />Now if you want succinct stacktraces in any java environment, set up your freaking lo4gj appenders right. <br /><br />All you need is add your root package. I'm guessing: 'test.framework'Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-25827813937439208602009-08-17T14:39:48.851-05:002009-08-17T14:39:48.851-05:00@Artur
I don't think there's anyone here ...@Artur<br /><br />I don't think there's anyone here that's said that the stack traces are great. Most of the responses come down to: 'they suck' or 'meh, don't care'<br /><br />What do you mean by 'native' stack traces? Cleaned up so there is less noise? If that's the case, I think Ted offered up the best compromise--a command line flag to choose between full traces and simplified ones.<br /><br />I did a quick google after Phil mentioned it and found: http://groovy.codehaus.org/api/org/codehaus/groovy/runtime/StackTraceUtils.html <br /><br />I haven't had a chance to see how much it cleans up the stack traces. From Phil's comment, it sounds like it might need some additional configuration to really get rid of the cruft.Josh Reedhttps://www.blogger.com/profile/02066492903706506905noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-53120088127140701252009-08-17T14:25:44.210-05:002009-08-17T14:25:44.210-05:00What I don't like is the mindset "It is g...What I don't like is the mindset "It is groovy, so whatever it outputs has to be great". What about agreeing that it would be great to see 'native' groovy stacktraces, but is is currently not possible or very hard to achieve that? And maybe looking for a usable solution, rather than requiring everybody to write filter scripts or wade through hundreds of lines of noise.<br /><br />I wonder if it would be possible to have some optional hack in groovy, which would cause exceptions to be recreated with reflection-injected StackTraceElement[] stackTrace field, which would contain groovy level info. It would have to be optional, because some people (especially groovy developers) would still prefer to see original stack traces.Artur Biesiadowskihttps://www.blogger.com/profile/01153887805003519136noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-15835932401965815702009-08-17T03:01:22.200-05:002009-08-17T03:01:22.200-05:00They're one of the reasons a console debugger,...They're one of the reasons a console debugger, like pdb, would be very useful in Groovy.geohttp://ssscripting.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-9395073135664086872009-08-16T16:46:53.425-05:002009-08-16T16:46:53.425-05:00You only have to look at many of the entries in Na...You only have to look at many of the entries in Nabble to wish that either 1) Groovy produced a lean stack trace, or 2) the user would only copy the relevant portion of the stack trace.Roshan Shresthahttps://www.blogger.com/profile/14389545211758295773noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-54567015233726503812009-08-16T14:48:17.913-05:002009-08-16T14:48:17.913-05:00I'll preface this by saying that I'm prett...I'll preface this by saying that I'm pretty ignorant when it comes to JRuby. So if I'm off base, then please correct me.<br /><br />It seems to me that the stack trace issue really stems from the fact that in Groovy you're always in 'Java integration' mode whereas in JRuby you are not. I can't imagine the JRuby guys have found some significantly better solution (with respect to the stack traces generated when calling Java libraries) that the Groovy team hasn't considered/borrowed. <br /><br />With that concession, I guess I would expect JRuby stack traces to be more to the point because they aren't doing all of the reflection jazz behind the scenes to make sure everything places nice from the Java side. When you start crossing that Ruby/Java boundary, I would guess that the stack traces become increasingly more hideous (unless they are sanitizing by default)Josh Reedhttps://www.blogger.com/profile/02066492903706506905noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-25953987342711938802009-08-16T14:31:39.272-05:002009-08-16T14:31:39.272-05:00yeah, horrid stack-traces are not a show-stopper. ...yeah, horrid stack-traces are not a show-stopper. but it's one of many irritating issues about groovy that has pushed me to using JRuby for my current project.phil swensonhttps://www.blogger.com/profile/14670058791716708777noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-91783489566515074802009-08-16T14:29:01.040-05:002009-08-16T14:29:01.040-05:00Note: I shouldn't have said "groovy suck...Note: I shouldn't have said "groovy sucks." I should have said "this sucks about groovy."<br /><br />Also note that that stacktrace I posted was using the groovy exception sanitizer utility and it still looked like that: <br />"}catch(Exception e){<br /> throw StackTraceUtils.sanitize(e)<br />}"<br /><br />I think that the groovy team doesn't want to fix it because there would be a large perf hit to resolve it. So what they should do is get a sanitizer that WORKS and add a method to Exception. So when the exception is to be presented to the user, just do a logger.excetion(groovyexception.sanitize()) or something similar.phil swensonhttps://www.blogger.com/profile/14670058791716708777noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-9305420171193090522009-08-16T12:08:15.930-05:002009-08-16T12:08:15.930-05:00From experience developing and deploying applicati...From experience developing and deploying applications into production, I can attest that Groovy stacktraces are not a showstopper.Scott Hickeyhttps://www.blogger.com/profile/14246732924788969410noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-34147139653400782132009-08-16T04:34:20.219-05:002009-08-16T04:34:20.219-05:00I agree that it should be a command line switch or...I agree that it should be a command line switch or something along those lines. Then, I'd give it one revision before having it set became the default...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-68677462360083001022009-08-16T03:05:47.195-05:002009-08-16T03:05:47.195-05:00Yes they are annoying, but I don't think they ...Yes they are annoying, but I don't think they are a showstopper. <br /><br />Jochen and the like are correct, eclipse and other tools should have a log filter that filters by package. Really, the problem goes to the root of how exceptions are reported by the JVM in the first place, and it has no way of package filtering the report.<br /><br />I don't think the Groovy team can be expected to alter that :D However providing an addition to the GREclipse plugin and others would be most welcome.matthttps://www.blogger.com/profile/17115089783697183273noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-35305868057519257422009-08-15T18:37:06.711-05:002009-08-15T18:37:06.711-05:00@Hamlet
I'll buy that it's the job of the...@Hamlet<br /><br />I'll buy that it's the job of the tools. I'll even grant that it's occasionally useful to see where things blew up in Groovy. But if the language designers are going to push it off onto the tools, they need to at least provide a useful API to do it (something like GrailsUtil.deepSanitize).<br /><br />The ability to expand that list would be nifty: app servers, frameworks, etc., all add stack frames on that don't really need to be there.<br /><br />@Berkay<br /><br />I don't buy the ops argument. If you're looking at the raw logs from production, you're doing it wrong. Feed it through a quickie perl script (or grep -v) to filter that stuff out. You probably need to be doing that in ops logs anyway: there's all kinds of noise in your average ops log.Robert Fischerhttps://www.blogger.com/profile/15576124960718643532noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-13515477653439742752009-08-15T18:26:41.650-05:002009-08-15T18:26:41.650-05:00I can see why people have a problem with them, but...I can see why people have a problem with them, but they never really bugged me. Grep for your package name and you've pretty much got a 5-10 line stack trace that's your answer almost all of the time.<br /><br />I agree with the groovy devs that tool support is the right place to deal with this.<br /><br />I do think that more work could be done by the tool devs, or maybe it'd be nice to have some sort of command line flag (-Dsimple.stacktrace=true) that filters things down for you. Might not be all that hard to implement with AST transformations.<br /><br />I like seeing all the detail as it gives me a better peek into what's going on under the covers.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-13858712956181683902009-08-15T17:19:05.928-05:002009-08-15T17:19:05.928-05:00A little interesting to get the hang of yes, but I...A little interesting to get the hang of yes, but I wouldn't call them an embarrassment or horrible. Stop reading once you see it start to be MOP stuff.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-19424440789771164432009-08-15T17:12:21.521-05:002009-08-15T17:12:21.521-05:00They are horrible from operations/support perspect...They are horrible from operations/support perspective. It fills the logs with loads of garbage, makes it very difficult to find what's going on.Berkayhttp://www.mberkay.comnoreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-11325379560420388172009-08-15T16:23:07.953-05:002009-08-15T16:23:07.953-05:00The Groovy Development Team seems to believe that ...The Groovy Development Team seems to believe that cleaning stack traces should be the job of tools. For instance, GroovyConsole cleans the traces, IDEA provides some filtering, and Spock provides some very useful filtering. There are methods in the GDK to clean the traces. I'm paraphrasing the mailing list here and quoting no one in particular, but the sentiment is that the language should not decide for you which information is useful and which isn't; that is the job of your tools. Writing a Grails plugin the cleans stack traces should be pretty easy (IDK for sure), as well as any other tools. <br /><br />But I agree that they are horrible. It's part of the learning curve that I'm over.Hamlet D'Arcyhttps://www.blogger.com/profile/04008870357169725586noreply@blogger.comtag:blogger.com,1999:blog-23881856886969249.post-7004553096018021472009-08-15T16:01:38.340-05:002009-08-15T16:01:38.340-05:00I'm downright embarrassed by Groovy's stac...I'm downright embarrassed by Groovy's stack traces, and they are pretty annoying to scroll back up through. The signal-to-noise ratio is really, really low.<br /><br />The Groovy impl based on invoke_dynamic will wipe out a lot of these extra stack trace frames. But that's Groovy 2 (if not later): JDK7 has to come out and be popularized.Robert Fischerhttps://www.blogger.com/profile/15576124960718643532noreply@blogger.com