Java has checked exceptions: if you have some code that can throw some specific kind of exception and you call it, the compiler will check that you properly handle the exception, either by catching it or by adding a 'throws' clause to your method to indicate that your method can throw the exception further.
If you catch (Exception e) then you are going against the whole idea of checked exceptions. You just catch any checked exception - it indicates that you haven't thought very hard about how to handle different kinds of possible errors. If you're just catching everything, then what sense does it make for the compiler to check that you're carefully handling any of the possible exceptions?
Because you will be catching much more than you should if you do that. You should only catch exceptions that you wish you handle, and let the rest propagate upwards through the stack. You should very rarely have any need to handle RuntimeExceptions and Errors, so catching Exception (or Throwable) is almost always inappropriate.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Say you had a method that reads data in from a file and returns the data. If you wrap a call to that function in a generic try...catch(Exception e) then you wont know what went wrong. Whereas if you try to catch specific exceptions, FileNotFoundException for example, then you can act on this information by informing the user that the file doesn't exist, rather than a more generic error message.
But in some cases it is ok to catch an exception in your way.
In development mode GWT throws a NullPointerException, while in productive mode a GwtException appears. So this is hard to handle, cause the easiest thing is to catch the parent "Exception" to catch both of the exceptions.
But this is a special case, in prefer to catch the specific exception(s). Often you need to distinguish between the different exceptions, f.e. to retry, close connection, ... .
In other cases it is possible that you catch an exception which you dont want do catch (cause the program cant accomplish any other task with this error/exception).
Joined: Aug 20, 2011
so if i catch Exception instead of any specific exception, is it wastage of resource??
(ie. memory), isn't it??
It's not related to any wastage or utilization of the resource, this is all about the logic whether you are handling these special events(exceptions) and how you are handling.
You might want to retry or pass through different branch if there is a particular exception, I can remember one case where we were parsing the XML/SOAP. But we didn't know that the input will be simple XML or a SOAP. So what we did we just tried to parse it as SOAP and if we get parsing exception then we assume it as a simple XML and proceeded successfully.
Do not wait to strike till the iron is hot; but make it hot by striking....
Jesper de Jong wrote:Java has checked exceptions: if you have some code that can throw some specific kind of exception and you call it, the compiler will check that you properly handle the exception, either by catching it or by adding a 'throws' clause to your method to indicate that your method can throw the exception further.
If you catch (Exception e) then you are going against the whole idea of checked exceptions. You just catch any checked exception
And you also catch one of the two major subtrees of unchecked exceptions. Bad idea in most cases.
Punit Jain wrote:so if i catch Exception instead of any specific exception, is it wastage of resource??
(ie. memory), isn't it??
No, it doesn't waste anything. The reasons to not just catch Exception are:
1) It takes away visibility and control over which exceptions are being caught. You don't get to handle different kinds of exceptions differently (unless you do something like instanceof inside your catch block, which would be icky).
2) If the code you're calling gets upgraded and starts throwing a different set of checked exceptions, the compiler won't be able to tell you about it. (This is, admittedly, a minor point, but it bit me once, and I'll never forget it.)
3) Catching Exception includes RuntimeException and all its descendants, and we usually DON'T want to catch those.