Is it good to catch a more general type of Exception?

Question

If we are to catch specific forms of IOException, or any other kind as a matter of fact, and we only try and catch a couple (and define definitive outputs for t

Answer 1

You should not catch these at every possible location where an IOException can happen but further up in the call tree where you are prepared to handle the remaining IOExceptions and the general Exceptions.

We use the rule of thumb, that you catch specific exceptions at the place where you can handle the error and pass the remaining ones up to the caller.

Answer 2

I think it is a matter of personal preference. Personally, this seems not to be a good choice. I prefer to have code that makes sense to me with the try-catch stuff. This means being as specific as possible. I would say:

try{
    //Code Here
}
catch(FileNotFoundException e){
    //Code Here
}

Answer 3

Generally, you should only catch exceptions you are going to handle explicitly.

You should not catch Exception, IOException, et. al., unless you are an appropriately high level where you are doing your last ditch catch to report a general error to the user.

Answer 4

I'll echo "catch the most specific exception you can".

I routinely catch IOException and display some sort of "error reading file" message, then allow the user to select another file or whatever is appropriate. If the file is really bad, there's probably not much the user can do about it, but at least you can let them know the file is bad.

If you get a FileNotFoundException the real problem is almost surely that the user seleected the wrong file name or a hard-coded file name is no longer valid. I routinely display messages for that.

I almost never catch "Exception". What are you going to do about it? There's pretty much nothing you can do to recover from "something went wrong but no further details are available". In some contexts I suppose you could at least display an error message rather than just dying, but that's about it.

Answer 5

Blankly catching any kind of exception is not a good idea. Yes, as a parent exception, it seems to provide a layer of "protection", but this is bad for a few reasons:

IOExceptions are checked. If there's nowhere in the code that's throwing it adding an unneeded catch just obscures things, and will likely confuse anyone looking at the code later.

More importantly, you don't catch exceptions to just make them go away. If they did, you could just wrap all your methods in (catch(Exception e){..}) and be done with it. Your exception catching code should be the place where you decide what to do if those errors happen, e.g.

catch(FileNotFoundException e)
{
 log.error("where's the file?");return null;
}
catch(ZipException e)
{
 log.error("corrupt");return null;
}

The point is to make the method well behaved under all possible conditions. The caller then deals with, for example, either file content or no content, without worrying about how the content got there.

Answer 6

Like a good consultant, I say "it depends."

In general in Java you have a clear idea of what all the possible exceptions at a particular point in the code might be. It's not uncommon to see someone use

} catch (Exception e){
   // log or stack trace
}

... in more or less throwaway code. In general, though, you shouldn't catch an exception you don't know how to handle usefully. (Never, never ever, do catch (Exception x) ;, ie, just throw away the exception. Never.)

The controlling thing is to ask "what can I do with this?" Often, a file not ound exception can be handled by asking a user where his file has gone. A zip file exception is harder to handle. Thus, you might want to have separate behaviors.

On the other hand, if it's a command line program, you might want nothing more than an error message in either case.

One other bit of advice; don't output a stack trace in "cutomer facing" code -- code that a non-programmer might see. Nonprogrammers tend to look at the compleities of a stack trace and panic. It's better to translate the exception to a message like "File 'filename' not found." and, if you really want a stack trace, ose logging to send it to debug level output.