harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: Some questions about the architecture
Date Fri, 21 Oct 2005 17:37:29 GMT
On 10/21/05, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Dan" == Apache Harmony Bootstrap JVM <bootjvm@earthlink.net>
> Dan> I agree that the verifier should look into this, but what happens if
> Dan> you get a divide by zero error?  Or a null pointer exception?  These
> Dan> are not available to the verifier, but are runtime conditions that
> Dan> do not arise in advance.
> The bytecode verifier doesn't need to know about exceptions at all.
> "Checked" exceptions are purely a language thing.  They are not
> checked by the runtime.
> Dan> Therefore, they need to be checked at
> Dan> run time and exceptions thrown.
> True.
> Dan> One question that I have is that in 'jvm/src/opcode.c' there are
> Dan> a number of references to thread_throw_exception().  The first
> Dan> parameter is the type of event, either a java.lang.Error or a
> Dan> java.lang.Exception or a java.lang.Throwable.  Can I get by
> Dan> without java.lang.Throwable?
> I read through the exception code a bit.  From my reading, I see a few
> flaws.
> First, there is no need to differentiate between throwable, exception,
> and error in the JVM.  'athrow' merely throws an object whose type is
> a subclass of Throwable.  The catch handlers do the type comparison at
> runtime to see if they should run.
> It isn't clear to me how THREAD_STATUS_THREW_UNCAUGHT is ever set.
> But, it doesn't matter, since I think this isn't needed.  Instead it
> is more typical to set up a base frame in the thread which essentially
> looks like this:
>    try {
>      .. run the thread's code
>    } catch (Throwable) { // this catches any "uncaught" exception
>      .. forward to ThreadGroup
>    }
> I.E, you don't need a special flag.
> In thread.h it looks as though the exception being thrown is thrown by
> class name:
>     rchar *pThrowableEvent;      /**< Exception, Error, or Throwable
>                                   * that was thrown by this thread.
>                                   * @link #rnull rnull@endlink
>                                   * if nothing was thrown.
>                                   */
> Typically it is simpler to unify the exception handling code so that
> internally generated exceptions (e.g., an NPE) are thrown using the
> same mechanism as user-code-generated exceptions.  In other words, I
> think you're going to want an object reference here.
> Tom

I think unless the vm extract the class name of the exception before
stack unwinding, it's required. One can, for example, throw an
exception using reflection:

  throw (Throwable)Class.forName("java.lang.Exception").newInstance();

View raw message