Re: exceptions & dataflow

David L Moore <>
9 Feb 1998 00:08:09 -0500

          From comp.compilers

Related articles
exceptions & dataflow (David James) (1998-02-03)
Re: exceptions & dataflow (Anurag Acharya) (1998-02-07)
Re: exceptions & dataflow (Sergey Solyanik) (1998-02-07)
Re: exceptions & dataflow (Jason Merrill) (1998-02-08)
Re: exceptions & dataflow (David L Moore) (1998-02-08)
Re: exceptions & dataflow (David L Moore) (1998-02-09)
Re: exceptions & dataflow (Sergey Solyanik) (1998-02-10)
Re: exceptions & dataflow (Jason Merrill) (1998-02-10)
Re: exceptions & dataflow (1998-02-10)
Re: exceptions & dataflow (1998-02-10)
Re: exceptions & dataflow (Jason Merrill) (1998-02-12)
Re: exceptions & dataflow (Fergus Henderson) (1998-02-12)
[5 later articles]
| List of all articles for this month |

From: David L Moore <>
Newsgroups: comp.compilers
Date: 9 Feb 1998 00:08:09 -0500
Organization: Netcom
References: 98-02-025 98-02-027 98-02-034
Keywords: optimize, Java, C++

Jason Merrill wrote:

> I'm not sure what you're saying. I'm not very familiar with Java, but
> finally blocks seem analogous to C++ implicit destructors in terms of
> when they get run;

They are different and the difference has an important implication for
exception handling.

In C++, you must destroy all variables on the stack when an exception
flies out. One way to do this is by generating an implicit "try" block
for every variable that has a destructor, like this:

the_doctor_must_be_annihilated X; // implicit "try" block starts here
// (just after the declaration)
} // implicit catch (...) required here

In Java, the finalizer is run when the storage for the object gets
garbage collected, which can be much later. As a result, you must have
enough information in the object to allow you to call the correct
finalizer but you need no implicit exception regions.

Until just now, as I wrote this, I thought that this was a win to
Java, since the exception tables will be smaller, but I realize that
you could use this implementation in C++ too. Whenever you create an
object on the stack you could put a pointer to it and its destructor
somewhere in a known spot so that when you unwind the stack you can
call the destructor. You would need a table in each activation
segment, and you would presumably put it at a fixed offset in the
segment, possibly preceded by a length indicator.

So actually, as an implementor you have more choices in C++ and you
can more effectively pay out in space to get time in C++ since, in
Java, you must store the extra information with each object whereas,
in C++, you can do it all with statically generated tables, or you can
use the Java like approach.

(BTW, is there any truth to the rumour that Indonesia's currency
crisis has been solved; Bill Gates is going to buy Java?)

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.