On 10/21/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Rodrigo Kumpera <[EMAIL PROTECTED]> > > 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.
