Forum Stats

  • 3,851,383 Users
  • 2,263,969 Discussions
  • 7,904,691 Comments

Discussions

Why are generic catch clauses prohibited?

843793
843793 Member Posts: 41,732 Green Ribbon
edited Apr 29, 2003 11:42PM in Generics
Does anybody understand why type variables are prohibited in catch clauses (spec page 9)?

I tried the following:

<E extends Exception> void g(E e) throws E {
throw e;
}
<E extends Exception> void f(E arg) {
try { g(arg); }
catch (IllegalStateException e) { ... } // 1st
catch (E e) { ... } // 2nd
catch (Exception e) { ... } // 3rd
}
f(new IllegalStateException()); // 1st
f(new java.io.FileNotFoundException()); // 2nd
f(new Exception()); // 2nd


It compiles. It works as one would expect. But the spec says it's illegal. Why would it be necessary to prohibit this?

Angelika

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Isn't it illegal to have an unreachable catch block? If that's the case, then if E was IllegalStateException or a subclass, or if E was Exception or a superclass, then the class whould not compile. Since E isn't known until later because of genericity, the construct should be prohibited.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon

    If the use of type parameters in catch clauses were prohibited in order to avoid unreachable catch clauses then the following were permitted:

    <E extends Exception> void g(E e) throws E {
    throw e;
    }
    <E extends Exception> void f(E arg) {
    try { g(arg); }
    catch (E e) { ... }
    }

    Since there is only one catch clause there is no danger of any unreachable catch clauses. According to the spec even that is prohibited. Why?

    I would understand if the spec would prohibit something like this:

    <E> void f(E arg) {
    try { g(arg); }
    catch (E e) { ... }
    }

    There is no hint whatsoever that E would be a subtype of Throwable. But as soon as the erasure of the type parameter is a subtype of Throwable I would expect that the type parameter can be used in a catch clause. Why not?





  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Because generics are implemented using erasure, there is not
    enough information at runtime to handle generic exceptions.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Yes, that explains it. Thank you. My initial example just worked by chance.

    In a method like this

    <E extends Exception> void f(E arg) {
    try { g(arg); }
    catch (E e) { ... }
    }

    the erasure of E would be Exception. The catch clause would then boil down to catch (Exception e). There is no compelling reason why this should not compile, but it is definitely nonsensical source code. I could equally well say catch (Exception e) instead of catch (E e).

    If I understand the spec correctly then the compiler should reject the code above with an error message. It's a "bug" in the prototype compiler that the code sample above compiles, right?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    If I understand the spec correctly then the compiler
    should reject the code above with an error message.
    It's a "bug" in the prototype compiler that the code
    sample above compiles, right?
    Right. That bug has long since been fixed. The next
    prototype (late May?) won't have this bug.
This discussion has been closed.