Better exception handling in Java 7 : Multicatch and final rethrow

I’m happy to announce that an other improvement from the Project Coin has be marked for inclusion in Java 7 : Improved Exception Handling for Java, from Neal Gafter. This has been announced by Joe Darcy on his blog.

This improvement add two litlte improvements to exception handling :

  • Multicatch : You’ll now be able to catch multi exceptions type in one catch block
  • Final Rethow : Allows you to catch an exception type and it’s subtype and rethrow it without having to add a throws clause to the method signature.

Often, we have that kind of code :

} catch (FirstException ex) {
     logger.error(ex);
     throw ex;
} catch (SecondException ex) {
     logger.error(ex);
     throw ex;
}

But that code is heavy for nothing really interesting. A solution is to find a common supertype of these two exceptions type and catch just that type and rethrow it. But that can catch more exceptions than you want.

So now, with that new feature, you can do :

} catch (FirstException | SecondException ex) {
     logger.error(ex);
    throw ex;
}

A lot more cleaner, isn’t it ?

And the second improvement is a little more complicated. Imagine that you want to catch all exceptions, make several operations and then rethrow it. The code isn’t hard to make, but the big problem is that you must add a throws clause to your method signature to manage the new exception launched by your code and this is not the objective. Now, you can do that without adding an exception throws clause :

try {
     // some code
} catch (final Throwable ex) {
     // some more code
    throw ex;
}

Using the final keyword it allows you to throw an exception of the exact dynamic type that will be throwed. So if an IOException occurs, an IOException will be throwed. Of course, you have to declare the exceptions not caught. You throws clauses will exactly the same if you use the code (in //some code) without catching anything but now you can do something if that happens.

I think multi-catch is a great feature, but for me the final rethrow is not often useful for programmers and perhaps a little weird using the final keyword.

 

  • http://www.javac.info/ Neal Gafter

    My name is spelled “Neal”, not “Neil”.

    • Baptiste Wicht

      I’m really sorry. This is corrected.

  • http://www.javac.info/ Neal Gafter

    My name is spelled “Neal”, not “Neil”.

    • Baptiste Wicht

      I’m really sorry. This is corrected.

  • http://codequirks.com Travis Calder

    The final-rethrowable appears to be a very strange case of “finally”.

    I could imagine a snippet where “//some more code” was stuff in the finally block, and the “catch” simply used a Multi-Catch. Should do approximately the same thing?

    That said, I think you could use it to essentially set up different “finally” behavior for different classes of exceptions (checked/unchecked). I just have a very hard time understanding why you’d want to.

    • Baptiste Wicht

      I cannot imagine in case in which this is the same thing…

      How do you know in the finally block if an exception has been thrown ? The objective for this new structure is to catch an entire branch of exceptions, make something and them rethrow it again.

  • http://codequirks.com Travis Calder

    The final-rethrowable appears to be a very strange case of “finally”.

    I could imagine a snippet where “//some more code” was stuff in the finally block, and the “catch” simply used a Multi-Catch. Should do approximately the same thing?

    That said, I think you could use it to essentially set up different “finally” behavior for different classes of exceptions (checked/unchecked). I just have a very hard time understanding why you’d want to.

    • Baptiste Wicht

      I cannot imagine in case in which this is the same thing…

      How do you know in the finally block if an exception has been thrown ? The objective for this new structure is to catch an entire branch of exceptions, make something and them rethrow it again.

  • Daniel

    Null-safe method access would have been nicer.

    After all, you can “emulate” multicatch quite easily:

    try {
    // … something that throws exceptions …
    } catch (Exception e) {
    if (e instanceof OneException || e instanceof OtherException) {
    // log
    } else (e instanceof IOException) {
    // log
    }
    }

    Still “chatty” but essentially the same :)

    • Baptiste Wicht

      Yes you can emulate, but in your case you catch all the Exception and that not the objective of this improvement. Or perhaps, I didn’t understand your example.

  • Daniel

    Null-safe method access would have been nicer.

    After all, you can “emulate” multicatch quite easily:

    try {
    // … something that throws exceptions …
    } catch (Exception e) {
    if (e instanceof OneException || e instanceof OtherException) {
    // log
    } else (e instanceof IOException) {
    // log
    }
    }

    Still “chatty” but essentially the same :)

    • Baptiste Wicht

      Yes you can emulate, but in your case you catch all the Exception and that not the objective of this improvement. Or perhaps, I didn’t understand your example.

  • Daniel

    Of course it should say “else if” in my previous comment.

  • Daniel

    Of course it should say “else if” in my previous comment.

  • Pingback: What’s In The Plate for Java 7?

  • Mehal Shah

    I like this, but I wish it was || instead of |.  In my head, || means “or” which is more in line with what is going on here

  • Pingback: The Empire strikes back – oder: Warum wir von Java noch einiges erwarten dürfen. | Accso Blog

  • Pingback: Project Coin: Java 7 Language Inhancement | Code Explosion

  • http://wisentechnologies.com/it-courses/java-training.aspx Java Training In Chennai

    interesting and good feature. It reduce the lot of typing for developer

    • http://www.baptiste-wicht.com/ Baptiste Wicht

      Indeed, it makes the good better :)