Amen.  I've worked on too many systems where there was no way to get a
stack trace other than by decoding a hex dump, and Java is to be
lauded for building in such a good mechanism.  Certainly it could be
improved, but it could much more easily be rendered useless, and that
would be a crime.

On Dec 1, 2:32 am, Kjetil Valstadsve <[email protected]> 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.
>
> Sorry for rambling on, I'll go get coffee now.
>
> Kjetil

--

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.


Reply via email to