Try/Multi-Catch vs Single Catch

Question

While adding a try/catch block in Eclipse, it gave me the option of "Surround with try/multi-catch" or "Surround with try/catch."

This is the try/multi-catch:

try { save.load(new FileInputStream(file.getAbsolutePath())); } catch (FileNotFoundException | IOException e) { // TODO Auto-generated catch block e.printStackTrace(); }

This is the single try/catch:

try { save.load(new FileInputStream(file.getAbsolutePath())); } catch (FileNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); }

What are the benefits/repercussions of using one or the other? If I'm correct, the first example will execute the catch block when EITHER of the exceptions are thrown and produce the SAME CATCH, while the second example will throw a catch based on the exception while enabling separate catch blocks.

Is there anything else I should know about this? I've never used them before and don't know if they are worth using.

If you're doing the same thing in both cases, use multi-catch. If not, then not. — Louis Wasserman
– Louis Wasserman, Commented Jul 14, 2013 at 1:00
@PaulBellora I had Eclipse auto-complete for me for the example. It's corrected in my real code. — Aaron
– Aaron, Commented Jul 14, 2013 at 1:03
@Aaron I'm with you, don't worry. I've seen Eclipse generate much sillier things, believe me. — Paul Bellora
– Paul Bellora, Commented Jul 14, 2013 at 1:20

nanofarad · Accepted Answer · 2013-07-14 01:00:23Z

tl;dr Mutlicatch handles things singlehandedly, multiple catch blocks are more flexible and nicer to operations. The two techniques can be combined.

If you have a try statement that can throw many different exception types, you'll want the multiple catch blocks. It's a bit more code but offers far greater flexibility.

For instance, if working with sockets, a SocketException may be caught with nothing more than a reconnect and/or an error message (as something as simple as an inadvertently disconnected cable may cause this)

If a null pointer exception(although it's unchecked) is caught, you're going to want to write to a log and make an emergency landing here, cleaning up what you can, and backtracking quite a bit codewise, possibly.

In addition, this can be subdivided even further, where different types of "common" exceptions may cause different actions to be taken(such as a connection lost vs name not resolved having different implications for the end-user on the first connection attempt) and different "heavy" exceptions being handled in different ways as well.

While you could have one (multiple exception type) catch block, it would either singlehandedly take similar action for all exceptions (presenting a null pointer exception to a user in the same way as a condition based on a cable being unplugged) or require if e instanceof FooException blocks that can decrease readability.

You can also combine the two, multicatching all "common" exceptions into a retry and nice message and all severe exceptions into a forced cleanup and shutdown

You don't want stacktraces for tripped cables, and you don't want to brush off missing objects.

Accepted when available for detailed explanation :) Learned a lot from your answer!

Ahmed Masud · Accepted Answer · 2013-07-14 00:57:13Z

This a choice thing. You want to balance readability, portability, maintainability and also handling different exceptions differently.

So balance the use ... If all your catches use the same block of handling then use the first form, because that's just one code block and you aren't repeating yourself over and over again. The compiler can optimize things out a bit for you.

On the other hand use the second form if you are handling each exception differently.

This is somewhat of a broad question and the answer is dependant on your goals.

KyelJmD · Accepted Answer · 2013-07-14 00:57:17Z

I believe that your first code snippet will only be applicable if your JDK is Java JDK 7. while the second snippet will still run in JDK 7 and below.

If you have a line of code that is possible to throw different types of exception and you want to handle them all in a similar way, Multicatch will fit you since it saves several lines of code.

however, if you have a line of code that will throw several exceptions, and you want to handle those exceptions individually, a single catch exception will fit you more.

johnchen902 · Accepted Answer · 2013-07-14 01:05:01Z

If you want to do the same thing for all exceptions, try-multi catch and try-catch are the same, except the former is shorter. _{All programmers are lazy.}

When you want to do different thing for different exceptions:

} catch(AException e) { System.err.println("AException occured"); } catch(BException e) { System.err.println("BException occured"); }

Try-multi catch is not the right choice.

} catch(AException | BException e) { System.err.println("A or B Exception occured"); }

Note that the type of e is the nearest common supertype of AException and BException.

Joe Babcock · Accepted Answer · 2013-07-14 00:57:40Z

Look, the actual utility of try-catch structures is that you can apply a specific error-handling function to a specific exception. In your case, it doesn't appear that you want anything to happen other than a stack trace to be printed. If I, for instance, wanted the window to close if a FileIOException was thrown, and I wanted simply an error message to appear if any other exception occurs, then it would be useful to have multiple try-catch blocks as you wrote in the second code block. In this application, though, you may just want to have a catch like this:

try { save.load(new FileInputStream(file.getAbsolutePath())); } catch (Exception e) { e.printStackTrace(); }

And that will print a strack trace for ALL exceptions. :)

The stack trace statements are auto-generated by Eclipse; he may want to do something other than print a stack trace.

Collectives™ on Stack Overflow

Try/Multi-Catch vs Single Catch

5 Answers 5

1 Comment

Comments

Comments

Comments

1 Comment

Linked

Hot Network Questions

Collectives™ on Stack Overflow

5 Answers 5

1 Comment

Comments

Comments

Comments

1 Comment

Linked

Related