As far as I understand, if you only declare a checked exception it will propagate through all your methods down to the main method and still interrupt your normal program flow and your program will still stop working. So, why not always handle checked exceptions with try/catch...so that way your program does not stop due to an exception? Why bother declaring an exception in the method's signature? Sorry for my bad English
Asked
Active
Viewed 1,863 times
3
-
possible duplicate of [When to choose checked and unchecked exceptions](http://stackoverflow.com/questions/27578/when-to-choose-checked-and-unchecked-exceptions) – Bohemian Mar 24 '12 at 15:04
-
1@dido: in addition to what Jon Skeet answered (that there are relatively few exceptions that you can genuinely handle), you've got to ask yourself this question: *"How are programmers able to work in the countless languages that do not even have the concept of checked exceptions?"*. Checked exception are pretty much specific to Java and there a *lot* of programmers in use daily written in languages that do not have the concept of checked exceptions. Checked exceptions also do *not* exist in your customer's problem domain. 300 KLOC codebase here where we do not throw a checked exception once. – TacticalCoder Mar 24 '12 at 15:10
-
possible duplicate of [The case against checked exceptions](http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions) – emory Mar 24 '12 at 15:53
4 Answers
11
As far as I understand, if you only declare a checked exception it will propagate through all your methods down to the main method and still interrupt your normal program flow and your program will still stop working.
Absolutely. And that's a good thing if something's happened that you really can't handle.
For example, suppose you've got a program which is going to update your database with some data in a file - but you fail to load the file.
You could just catch the exception, ignore it and still overwrite the data in your database... but that would not be a good thing. As soon as you're in a situation you weren't prepared for, or you fundamentally can't continue sensibly, then stopping is the responsible thing to do.
Sure, if you can genuinely handle the exception and keep going, that's great - but in my experience, there are relatively few errors where that's the case. If you're writing a server-side application you typically want to abort the request (and give an error to the client). If you're writing a UI then you may want to just abandon the current operation, notify the user and let them keep going... it's a slightly different situation there.
But unconditionally catching all exceptions and pretending they didn't happen? <shudder>
Jon Skeet
- 1,421,763
- 867
- 9,128
- 9,194
-
fyi, I think he means *unchecked* (which will propagate up). Your answer is good though :) – Bohemian Mar 24 '12 at 15:06
-
1@Bohemian actually I think he really means _checked_ exceptions, since he's talking about having to declare them in the method signature. – Thomas Mar 24 '12 at 15:09
3
The point of exceptions is that you can choose at which level to catch them; you don't have to do it immediately - sometimes that is the right thing to do, but a single top-level catch clause can handle all the other exceptions by logging them and then skipping to the next task/request (e.g. in a servlet container).
Java's checked exceptions try to make this mechanism more explicit by forcing you to either handle or declare exceptions. This prevents you from forgetting about exceptions you'd want to handle immediately.
However, many people think that it was a failed experiment in language design (note that no other language adopted checked exceptions) because it forces you to have some exception-related code at all levels - exactly what exceptions are designed to avoid.
Michael Borgwardt
- 342,105
- 78
- 482
- 720
1
For instance, if the calling method is able to handle the exception better.
Say you have some method for reading a file. How would that method know what needs to happen if the file doesn't exist? Perhaps the entire program should terminate, perhaps we should inform the user with a popup, perhaps it should log the exception and continue, perhaps it should try to restore the file from backup. Only the calling method knows, so it should implement the exception handling.
meriton
- 68,356
- 14
- 108
- 175
0
It's for more complex systems. Whoever is using your code higher up the chain may want to know about whatever went wrong, so you let them handle the exception. It doesn't go all the way to main necessarily(and can't really, unless EVERY method in the stack throws that exception, which would defeat the whole purpose.
