To be clear: All I want is that Throwable's methods, in particular:

        StackTraceElement[] getStackTrace()
        Throwable getCause()

continue to work exactly as they have, unaffected by any upcoming annotations. 
This strikes me as the wrong forum for talking about such changes anyway, but I 
felt compelled to nip it in  the bud (or at least point out the bud) in case 
the meme travels from here to spheres more influental ... (I guess everyone 
remembers how ClassCastException suddenly stopped reporting the actual class!)

Kjetil

On 2009-12-01, at 13:34 , Daniel Hicks wrote:

> On the JVMs I worked on there was an internal attribute that did this,
> but it wasn't exposed.  I'm guessing there's one in Sun's
> implementation as well.
> 
> On Nov 30, 10:00 pm, Neal Gafter <[email protected]> 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.
>> 
>> Cheers,
>> Neal
> 
> --
> 
> 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.
> 
> 

--

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