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

[Mohan Embar <gnustuff at thisiscool dot com>]

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. You can therefore argue that the caller is effectively checking
for a null return value, even if the semantics are different. Given
this, and the problematic nature of trying to conditionalize this in
any other way, why not just have findCallerClass() return null and
let the caller deal with this however s/he sees fit?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/