Irfan Khan
Irfan Khan

Reputation: 402

Use of multi exception catch in Java 7

Other than grouping similar exception types, what are the other advantages of handling multiple exception in one catch block over handling it using base Exception class?

Why to prefer this :

try{
        //some code
    }
    catch(FileNotFoundException e1 | IOException e2){

    }

Over this (This is less verbose) :

 try{
            //some code
        }
        catch(Exception e){

        }

Upvotes: 1

Views: 103

Answers (3)

Stephen C
Stephen C

Reputation: 719346

The two pieces of code are not equivalent.

The first one catches ONLY FileNotFoundException, IOException and their subclasses1.

The second one catches the above PLUS all other checked exceptions AND all unchecked exceptions (apart from Error and its subclasses). So:

  • You would be catching a whole bunch of exceptions that are typically a result of programming error; e.g. null pointers, problems with indexing and so on.

  • You are effectively "turning off" the checked exception mechanism which would give you a compile time error if you forgot to handle some checked exception; e.g. SQLException. Now at this point in time your code probably doesn't throw any checked exceptions apart from the ones you are catching (in version #1). But what happens if you modify the code to call some method that (say) throws SQLException:

    • With version #1 ... compilation error. Ooops, but you can fix that.
    • With version #2 ... no compilation error. Lets hope that your unit and systems tests are good enough to pick up the problem.

So, to answer your question ...

Why to prefer [version #1] ... over [version #2] (This is less verbose) :

You should prefer the one that is correct, not the one that is less verbose. The second version will catch exceptions that you (probably) don't intend to be caught, which makes it incorrect.

Prefer version #1.


1 - Note that FileNotFoundException is a subclass of IOException so you could rewrite version #1 to catch IOException only. If "verbosity" is your main focus, then catching BOTH IOException and FileNotFoundException is verbose.

Upvotes: 0

suroh
suroh

Reputation: 917

Well it's more about being efficient and effective in your exception handling, you've got quite a few ways of doing things like this. Also keep in mind that when you're working on a project big or small depending on what you're doing attempting to use some thing like

try{


 }(catch Exception e);

on a program (for example) using Encryption you'll get a ton of errors, like

NoSuchAlgorithmException 

InvalidKeyException 

And much more because that base Exception can't handle them.

When you use a compiler and each one is different... but in general they will all give you some form of a warning basically telling you " Hey Exception e wont handle this"

You'll also see that you'll have the ability to do things like this.

public setStringExample(string example) throws IOException, Exception, NullPointerExcetptiopn {

 } 

Java in a lot of ways forces you to account for most things which isn't really a bad thing I guess lol..

TL;DR The overall point I'm trying to make is that Exception handling should be done properly and efficiently which is learned over time, don't try to catch some thing that isn't their and don't try to avoid catching some thing that probably will be!

Upvotes: 0

Andy W
Andy W

Reputation: 400

Catching generic Exception will also catch NullPointerException, IndexOutOfBoundsException and other exceptions that you generally don't want to catch. By catching the specific exceptions you want to handle you can avoid these situations.

Upvotes: 3

Related Questions