Wanted: multiple exception-type catch blocks

March 12, 2003 11:29 AM

The following would be incredibly simple to implement in the compiler, would require no VM changes, and would tidy up a lot of source code. How about it, Sun. With a bit of a push, you could get this into 1.5 easily.

(Just a spoonful of syntactic sugar helps the medicine go down...)

try {
   // blah
} catch (RemoteException, NamingException, CreateException
    as Exception e) {
   // blah

Obviously, the ‘target’ exception type would have to be a superclass of all the exception types being caught in that block. Any exception that does not match the types in the list falls through, even if it is still a subclass of the target exception.

The only downside of the way I've written it is that it introduces ‘as’ as a new keyword, which might break some code, but you could always cheat and substitute some kind of punctuation instead.

3 TrackBacks

Listed below are links to blogs that reference this entry: Wanted: multiple exception-type catch blocks.

TrackBack URL for this entry: http://fishbowl.pastiche.org/mt-tb.cgi/181

Charles Miller wants to be able to catch multiple Exception types in a single catch block. Well, you can do Read More

Charles Miller wants to be able to catch multiple Exception types in a single catch block. Well, you can do Read More

Charles Miller wants to be able to catch multiple Exception types in a single catch block. Well, you can do Read More


I was looking for a lost friend with the same name maybe
this was an accident or divine guidence I started a peace
movment ( world federation for peace ) promoting world
union(an alternative organisation to united nation)with no
Vito rights .may your sleepless nights & dreams making you ready for a bigger responsiblity towards your fellow
humanbeings .we need some one to do our website.
you might one day join us and world becomes one.

In the light of the previous comment, I'd just like to state that if you don't hear from me for a few weeks, I've probably been kidnapped by the Raelians.

I think this is a brilliant idea. I have wanted this feature since I started programming in Java (1996).

a definite +1 to that idea.

This is a really interesting idea. You can actually do something approximating this in .NET using exception filters, and I've written a very quick example: http://headblender.com/joe/blog/archives/geekness/000971.html

Of course, it's not nearly as clean a syntax as what you're suggesting, and I only mention it because it's really the first useful scenario I've seen that exception filters enable. (Also, I'm not trying to provoke any "Java vs .NET" flames, I'm just pointing out something I thought was interesting.)

Very good idea, and I think perhaps another goodie could be "implicit method try-catch", like this:

public void methodX(String arg) throws RemoteException, FinderException, Exception as e {

...and inside the method just do:

catch(e) {


That would really rock!

Sounds great. A way to resoulve the 'as' keyword issue would be to allow the catch to behave like a method declaration:

try {
// blah
} catch (RemoteException re, NamingException ne, CreateException ne) {
// blah

This seems a bit confusing.

Why not do a catch (Exception e) with an 'instanceof' check on the three target types and if the condition fails rethrow the exception?

The "catch everything, do an instanceof check and then rethrow everything that remains" doesn't work because you end up having to throw "Exception" in your method signature. Which is a Bad Thing. And anyway, it's overly verbose, which is just what I'm trying to escape from.

When I start finding myself with five different exception types to deal with, I find myself very commonly writing:

try {
// blah
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
// blah

This is also bad, because if you alter the method and something inside the try block throws a new kind of exception, you don't get alerted to this fact by the IDE or the compiler, and your default catch block may be inappropriate for the new kind of exception.

The idiom I suggested encourages better exception handling in programmers by making it easy to write blocks that deal coherently with the myriad, un-related exceptions that things like EJB and Reflection can throw, without taking a shortcut that ultimately turns out to be bad design.

It helps in better exception code organization.

Say for example I want do the same thing for multiple exceptions, this really would helo.
It may be easy to implement for compiler like this ( && wouldnt make sense though :)

try {

} catch ( org.omg.CORBA.INV_OBJREF || org.omg.CORBA.OBJ_ADAPTER || org.omg. CORBA.COMM_FAILURE e ) {
// delete local object reference
} catch ( Excetpion e ) {

Previously: HTML peeve: image captions

Next: Change of Address