DRAFT PROPOSAL Pot Pourri - Augmented Stack Traces, ServiceProvider annotation and processor, Enhanced For Loop utility class

[Bruce Chapman & Barbara Carey]

Charles Oliver Nutter wrote:
>
> I wonder if a general mechanism for decorating the stack could be part 
> of this? My understanding of exception handling performance is such 
> that handling the exception is actually the more expensive part; so I 
> would expect that handling and re-handling to augment the exception at 
> various levels would add more overhead. One thing I've often wanted is 
> a way to decorate the stack with additional information *ahead of 
> time* so that when/if an exception is raised that information can 
> automatically be attached. In my case, it's for JRuby, where we have a 
> "virtual" Ruby stack trace alongside the Java stack trace. It's not 
> useful for us to dump out the entire Java stack trace, since it 
> includes information about Java frames unrelated to the user's code. 
> And we can't just filter  the Ruby frames, because JRuby is mixed-mode 
> and some of those frames will be interpreted calls (and therefore be 
> identical to one another). A way to attach information to the current 
> frame (Thread.current.augmentFrame(Object)) and register a backtrace 
> handler (Thread.current.attachBacktraceCallback(...)) would provide a 
> way to attach useful arbitrary data to the call frame for many uses.
>
> Thoughts?
>
> - Charlie
>
Thanks for the comments.

I had initially though of a similar mechanism to that. See 
http://weblogs.java.net/blog/brucechapman/archive/2007/08/index.html

However that requires quite deep changes in the JVM and the JVM spec and 
probably the language.

My proposal can do similar with a little more effort from developers 
(over-use is probably to be discouraged so some effort is a good thing 
IMHO), with just a library change (albeit changes to Throwable and 
StackTraceElement which are pretty core), feasibility of actually doing 
it trumps performance :)

If my proposal made it into a future JDK release (it can't be done as an 
add on library) and was well accepted but performance was shown to be a 
problem, then a declarative approach to the augmenting data could be 
added to the JVM. later (maybe)

Performance wise some inital tests showed that avoiding filling in a new 
(reusable actually) stack trace in order to get the depth at which the 
augmentation should occur roughly doubled the performance, so that 
second stack trace chewed up quite a few horsepower.

Regards your ruby project, I think you should be able to grab the stack 
trace for an exception, and replace it with a manufactured stack trace, 
with manufactured stack trace elements. I have been successful in using 
this technique to augment stack traces (albeit I was suffixing the 
context info after the method name with inverted parenthesis around it 
to make it look like it was another item in the stack trace element.)

Bruce