[3170] in java-interest

home help back first fref pref prev next nref lref last post

Ordering semantics of runtime exceptions

daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Thu Nov 2 04:16:17 1995

From: "Jeremy Fitzhardinge" <jeremy@suede.sw.oz.au>
Date: Thu, 2 Nov 1995 17:56:15 -0500
To: java-interest@java.sun.com

Hi all,

I'm wondering if a compiler/runtime is allowed to reorder runtime
exceptions with regard to each other and global data updates.  If such
reorderings are allowed, what are the exact rules?

If they are not, can I suggest considering that they be allowed, since
there are lots of common cases where better code can be generated, on the
assumption that runtime exceptions don't happen in the general case, and
that programs don't use runtime exceptions as part of their normal
execution logic.  This would be particularly applicable for array bounds
checks and null pointer checks.

I suppose another way of looking at it is: can a program deliberately
induce runtime exceptions and get a predicable behaviour?

I assume that exceptions thrown explicitly with "throw" are always strictly
ordered with respect to each other and global data updates (except perhaps
for "threadsafe" class members).

	J
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post