Reputation: 402
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
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
:
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
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
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