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 20:07:21 GMT
On 10/21/05, Apache Harmony Bootstrap JVM <bootjvm@earthlink.net> wrote:
>
>
> > -----Original Message-----
> > From: Rodrigo Kumpera <kumpera@gmail.com>
> > Sent: Oct 21, 2005 12:08 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: Some questions about the architecture
> >
> ...snip...
> > > I agree that the verifier should look into this, but what happens if
> > > you get a divide by zero error?  Or a null pointer exception?  These
> > > are not available to the verifier, but are runtime conditions that
> > > do not arise in advance.  Therefore, they need to be checked at
> > > run time and exceptions thrown.  These two examples are subclasses
> > > to java.lang.RuntimeException and may be thrown at any time.
> >
> > There are no diferences from the exception handling (define the catch
> > of an exception) perspective between explicit thrown exceptions (no
> > matter the Throwable subclass) and runtime generated ones (CCE, NPE,
> > etc). The only diferences are on the verifier (verify checked
> > exceptions) and how they are trapped (NPE could use the segv signal).
> > I don't understand your (un)protected exception classification.
> >
>
> Perhaps I need to use more standard terminology.  In place of
> "unprotected", I should say "uncaught".  (Sorry about that!  I'll try to
> get my terms straight here.)  This means an exception without
> an explicit handler, which could include a java.lang.RuntimeException
> or a java.lang.Error.  The VM spec sections 2.16, 2.16.2, and 2.17.7
> discuss uncaught exceptions.  This is why I have felt I had to make a
> distinction and so implement my code.

The thing is, there's no need to make such distinction.
What happens when an exception is uncaught is, more or less, the following

-The exception is passed to the thread's uncaughtExceptionHandler
-The exception is passed to the ThreadGroup's uncaughtException method
-The thread is terminated
-If this was the last non-daemon thread, terminate the JVM.

It's easy to have this stuff implemented in the class library, and not
in the runtime, using Java a well smaller code. The class lib just
make sure that no thread will ever have an uncaught exception of any
possible kind.

That's my point, at least.


> >
> > > Try taking a look at the JVM specification, section 2.16.  I have tried
> > > to write my code to implement the functionality described there.  I
> > > would appreciate you studying section 2.16 and comparing it against
> > > my implementation of the exception mechanism to see if you find
> > > any flaws in my logic.  If so, please let me know what you find.  One
> > > question that I have is that in 'jvm/src/opcode.c' there are a number
> > > of references to thread_throw_exception().  The first parameter is the
> > > type of event, either a java.lang.Error or a java.lang.Exception or
> > > a java.lang.Throwable.  Can I get by without java.lang.Throwable?
> > > Everything I throw so far is either an Error or an Exception.  I just
> > > included Throwable in case I had something else because I think I
> > > remember something in the spec about "something that is not an
> > > Error or an Exception," so I thought I would try to cover all angles.
> > > Thanks for your help.
> > >
> > >
> > > Dan Lydick
> > >
> > > ---
> >
> > Reading "2.16.2 Handling an Exception" I could not find any diference
> > between how Exception and Error exceptions are handled. The section
> > only defined how an expression/statement is dynamically enclosed by a
> > catch block. And even then, there are no distinction between explicit
> > throws, runtime generated exceptions and asynchronous exceptions.
> >
>
> VM spec section 2.16.4 makes that distinction, but I'm still wondering if I
> can get by without distinguishing java.lang.Throwable here.
>
>

Yes, 2.16.4 makes some distinctions, but I cannot see how they are
important to the runtime unless for bytecode verification purpoises.

Mime
View raw message