Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of kumpera@gmail.com designates
 66.249.82.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=KHJpFD+29UIzz5HOaXwOG9TsKPrywtxYPiucGv8B7gssFOg8zEIKN+PCeyx9EqddASo9LPLw4AWs6jwk6VaB6WqxmW/aGdtU6gxbDZhONjl0ZE2uKDbyt/pkFhXfZrBPb8X6U8Lq3hZi1vstEayUCSIoy79LbgBDOX1Lio1FnxY=
Message-ID: <8cca42d80510211037t50820462o13c8472912ec80c6@mail.gmail.com>
Date: Fri, 21 Oct 2005 15:37:29 -0200
From: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org, tromey@redhat.com
Subject: Re: Some questions about the architecture
In-Reply-To: <17241.8940.91105.740493@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
 <18781584.1129908462780.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net>
	 <17241.8940.91105.740493@localhost.localdomain>

On 10/21/05, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Dan" =3D=3D Apache Harmony Bootstrap JVM <bootjvm@earthlink.net> w=
rites:
>
> 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();