Re: [PATCH] Java: @deprecated handling, division by zero detection.

[Andrew Haley <aph at cambridge dot redhat dot com>]

Alexandre Petit-Bianco writes:
 > 
 > Andrew Haley writes:
 > 
 > > Can you please explain what you're trying to do here?  As far as I
 > > know the divide by zero handling was correct.
 > 
 > Here's a test case:
 > 
 >   class x {int i = 1/0;}
 >   class y {
 >       public static void main (String[] arg) {
 >           try {new x ();}
 >           catch (Exception _) {System.out.println (_.toString());}
 >       }
 >   }
 > 
 > A unpatched compiler (a 3.0.x compiler for instance) compiles this and
 > our runtime handles the exception correctly.
 > 
 > javac or jikes won't build it:

Right.  Now I see what you are trying to do.

The trouble is that this is dangerous.  For example, it might be that
a program that compiles on other compilers won't compile on gcc if we
do better constant folding.

IMO if we don't have to check this, and the specs don't say that we
do, we shouldn't.  We don't risk anything by compiling it.  We could
issue a warning.

 > I think that both behaviors are acceptable. Since what will happen
 > computing 1/0 is known in advance, the compiler might as well try to
 > prevent it. If generating an exception is the desired behavior, it
 > could rather be thrown.

It could, but this behaviour is not language spec compliant.

Consider this:
  
  if (thing that never can happen) 
     return 1/0;

According to my reading of the language spec this is a perfectly legal
program, will never throw an exception, and we shouldn't reject it.

 > It's a case of adhering to the specs -vs- being compatible with
 > other tools behaviors (the discussion most likely already took
 > place, I can't remember what we decided, but this should be
 > included in our hacking guidelines and our FAQ BTW.) I thought
 > getting the compiler involved would be more beneficial, but I'm
 > open to a change.

We're risking breaking compatibility for no good reason.  IMO.

Andrew.