Re: Updated throwable and stacktrace printing patch

[Andrew Haley <aph at cambridge dot redhat dot com>]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >Mark Wielaard writes:
 > > >
 > > > I wrote the code assuming that we want our stacktraces to look just like
 > > > conventional VM stacktraces and I believe this patch does that very
 > > > nicely. But maybe I have to think outside the box to see what you are
 > > > proposing here. (My box does not really include C or C++, as you have
 > > > seen, my main programming experience is with logic/functional languages
 > > > and some java.)
 > >
 > >That's to assume that the "conventional" VM stack trace is, in some
 > >way, ideal.  However, I don't accept that it is ideal in our
 > >environment where we link to CNI and JNI code and sometimes interact
 > >with other languages and system interfaces.
 > >
 > >My approach to libgcj has been that we should try to do better than
 > >conventional VMs when we can.  I believe that an informative stack
 > >trace is one such opportunity.
 > >
 > 
 > I believe that for most GCJ users, it is better that the stack trace 
 > resemble the traditional VM stack trace as closely as possible.

I'm not sure that I agree with all of this, but I'm pretty sure that
if it came to a vote I'd lose.  So, I give up.  However, I reserve the
right to say "I told you so" the first time we have to ask for more
information that would have been provided by an uncensored stack
trace!

 > The 
 > problem with having too much additional information in there, such as 
 > the PC for each frame, ambiguates the reason for the stack trace: 
 > _quickly_ figuring out where and possibly why an exception occured.

I don't know why you bring that up.  You snipped the part of my reply
where I made it clear that I wasn't in favour of printing the PC for
each frame.  This seems to me like a disingenuous debating tactic.

 > Many people will, in the course of debugging their application, want 
 > more information than the stack trace can provide and can use gdb to get 
 > far more information than a stack trace could ever provide. Thats what 
 > its for!
 > 
 > I accept your argument that it may not be convenient for embedded 
 > developers to use gdb and thus displaying the PC would be useful in an 
 > embedded environment.

What's "embedded" anyway?  Think of a server that runs for a month and
then corpses.

 > It also seems reasonable to display the PC in the 
 > event that line number information is unavailable. But in the general 
 > case, the PC is unneccessary information for casual Java developers 
 > which clutters the stack trace.

"Casual" Java developers?  Are you sure?  :-)

 > There should certainly be an option to switch on verbose stack traces 
 > (and in the future we need to do a much better job of documenting 
 > libgcj's knobs), and perhaps it should be the defualt for embedded 
 > targets. But by default, I think simple, clean, stack traces should be 
 > used.

I disagree, but I bow to the majority.  

Mark, please check in your patch.

Andrew.