[3185] in java-interest
Re: Ordering semantics of runtime exceptions
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Thu Nov 2 16:43:48 1995
Date: Thu, 2 Nov 1995 10:24:13 -0800
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: jeremy@suede.sw.oz.au
Cc: java-interest@java.Eng.Sun.COM
Hi Jeremy,
> 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?
I suppose that reordering is allowed as long as the exceptions aren't
moved to outside a significant try-catch block. Applications should not
rely on the order and place where RuntimeExceptions occur.
> 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 agree that this is useful and should be allowed.
> I suppose another way of looking at it is: can a program deliberately
> induce runtime exceptions and get a predicable behaviour?
You can throw RuntimeExceptions. You can also rely on certain runtime
exceptions to occur, but the compiler could move them around a bit.
> I assume that exceptions thrown explicitly with "throw" are always strictly
> ordered with respect to each other and global data updates
I'm not sure if we can make this claim. On an MP system this may be to
expensive to guarantee.
> (except perhaps for "threadsafe" class members).
We no longer have threadsafe class members. We've gone back to volatile...
Have fun,
Arthur van Hoff
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
