JDK-4708394 : generics specification breaks exception checking
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.4.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,solaris_8
  • CPU: generic
  • Submitted: 2002-06-26
  • Updated: 2008-04-24
  • Resolved: 2008-04-24
Related Reports
Duplicate :  
Duplicate :  
Description
Currently, the language provides no way to throw a checked excption without
either catching it or declaring it to be thrown in the current method.
(Notwithstanding a deprecated methon in Thread)  The generics prototype
introduces a way to throw a checked exception with only a warning, which
is suppressed by default.

I believe this is a serious regression in the language.  We should not
introduce such loopholes in type checking.

class Main {
    static void hiddenThrow(Throwable t) {
        class ExceptionHider<E extends Throwable> {
            void hiddenThrow(Throwable e) throws E {
                throw (E) e;
            }
        }
        new ExceptionHider<RuntimeException>().hiddenThrow(t);
    }
    public static void main(String[] args) // no exception in method declaration
    {
        hiddenThrow(new java.io.IOException()); // throws IOException, hidden
    }
}

Comments
EVALUATION I'm sorry, but this isn't a regression, because it isn't new. It is not unique to generics either. Consider: class Main { static void hiddenThrow(Throwable t) { throw (RuntimeException) t; } public static void main(String[] args) // no exception in method declaration { hiddenThrow(new java.io.IOException()); // throws IOException, hidden } } ###@###.### 2002-07-11 On the contrary, your program does not throw IOException, it throws a class cast exception on the attempt to cast IOException to RuntimeException. This is indeed a regression and it is unique to generics (excepting Thread.stop). ###@###.### 2002-07-11 I should have corrected the comment in the program above. My point is that it is simple enough to mask the *compile-time* errors regarding exception handling. The example above fails at run time (which is the bottom line) because an abstraction was created to mask the compile time checking. In this respect, its implications for security and compile time checking are very similar to the example given in the bug description. What I will concede is that now, the failure at run time will be a checked exception not a cast exception. But it still stems from using casts in your program. Clearly, some people will be inclined to make a big deal out of this. I am not. Obviously, this is related to run time support for generic type information, and is part of the price we pay for its absence. Until we have data on the compatibility and performance of such support, this won't change. Therefore, I'm inclined to reclassify this as an RFE. ###@###.### 2002-07-12
12-07-2002