This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gnu.gcj.runtime.StackTrace.findCallerClass()


Mohan Embar writes:
 > Hi Andrew,
 > 
 > > > >>If HAVE_BACKTRACE is not set, do not scan the stack but return null.
 > > > >>
 > > > >>If HAVE_BACKTRACE is set, we believe that backtrace() works.  So,
 > > > >>throw an exception if we don't find a caller.
 > > > >>
 > > > >>I await the firestorm...
 > > > >
 > > > >Um, I thought about this too but, you know the obviously glaring question
 > > > >so can you pre-emptively answer it?
 > >
 > >Sorry?
 > 
 > Sorry for the confusion. What I meant is: if we throw an
 > exception/error/throwable in the HAVE_BACKTRACE and require that
 > the caller check for null in the non-HAVE_BACKTRACE case, isn't
 > this breaking encapsulation and putting undue burden on the caller?
 > It seems like the caller will be faced to choose between two
 > dilemmas:
 > 
 > - catch an exception, forget about the null-checking case and possibly
 > unwittingly blow up with a NPE.
 > - know that you have to deal with both cases, and now be required to
 > introduce #ifdef HAVE_BACKTRACE in the caller's code too because there's
 > no other way to effectively deal with this.
 > 
 > Even in the current case, the caller is always catching the
 > ArrayIndexOutOfBoundsException and never letting it trickle up to a higher
 > level.

But that's wrong -- the caller shouldn't do that.  The only reasonable
thing to do if a caller isn't found in the stack is stop the entire
JVM with a RuntimeError.  Something has gone badly wrong.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]