[1147] in java-interest
No subject found in mail header
daemon@ATHENA.MIT.EDU (0000-Admin(0000))
Fri Aug 25 02:57:13 1995
Date: Thu, 24 Aug 1995 20:39:26 -0700
From: 0000-Admin(0000) <daemon@java.sun.com>
Apparently-To: java-interest-recipients@webrunner.neato.org
Hi all,
I'm wondering about the precise semantics of runtime generated exceptions,
particularly in the presence of other global effects. For example, can
exceptions ever be thrown out of order in relation to the source's flow of
control (or more concretely, is an optimiser allowed to reorganise code so
that exceptions may happen out of order)? Note that I'm only talking about
exceptions like NullPointerException, NegativeArraySizeException, etc.,
when generated by the runtime as opposed to an explicit "throw" statement.
The reason I ask is that lots of operations in Java which would normally be
side-effect free can have side effects in exceptional conditions (array
access, for example). If the compiler is not allowed to reorder exceptions
with respect to other code, then it limits the optimisation possibilities
quite a lot. For example:
a = thing[j];
j_fetched = true;
b = thing[k];
Just from looking at this extract, there are no dependencies between the
three statements. However, if they are all in an exception catch block,
and thing[k] throws an exception, the handler might expect j_fetched to be
true.
Is this a justified assumption?
It gets worse when you think that every object dereference could
potentially throw an exception.
So: does anyone have code which makes use of:
- ordering between runtime generated exceptions
- ordering between "global" side-effects and exceptions?
If no code does this, and/or it's deemed non-portable,
can I suggest that Java adopt a rule to the effect of something like
"a function can either have consistent global state or throw an exception",
where "function" is actually "any code running in a catch block" (so that
it's up to the catcher to get any global state consistent where necessary),
and "global state" is any side-effects which arn't exceptions (i.e.
variable updates, new objects, etc).
Perhaps one could overload "synchronized" blocks as a way of making sure
that exceptions happen in a limit scope (something like the Alpha's "trap
barriers").
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
