@TheCPUWizard said:
@arh said:
With it, you can define what exceptions are thrown...
The problem with checked exceptions, is that you can not define what exceptions may be thrown by a piece of code as soon as it calls into any other code. Even if you could determine all of the possible exceptions today, a library routine could be updated to introduce a new exception your code is not aware of.
I am a strong believer that exceptions should only be caught if there is seomething that can be done to address the situation that caused the exception. All other exceptions should be totally invisible and propogate to the next higher level, and if there is no level which can do something "graceful" in the event of the exception, the application should be torn down immediately and rudely.
Whoah. If you replace a library you'll get a compile-time error when you rebuild your application. (If you are replacing libraries without doing a rebuild, you are doing it WTF style and deserve whatever befalls you.)
I don't know your background, but I can tell you that tearing the application down "immediately and rudely" is pretty much 100% not the right thing to do with any GUI-based application or server/service based application. Maybe you are in a different neck of the woods where that's the expected behavior.
Here's why I like checked exceptions. Let's say I have a method called "void PayrollSystem.printPaycheck(Employee emp)". Now, we can have all kinds of fun discussions about what class this method should be in, and what parameters it should take, but that isn't the point here. The point here is to think about what can go wrong when we call printPaycheck(), and how we might handle those problems. If we're running in a development/test environment, there are some silly things that can go wrong, like passing null, or maybe a divide by zero because the employee was on vacation for the entire payperiod (and is paid hourly). These kinds of failures are the programmer's fault. They're bugs in the logic of the code.
There's another set of failures that can occur when the application is actually deployed and running in a customer's environment. Let's say that printPaycheck() has to go to the database to fetch some data, invoke a web service, create a PDF file, and then send that PDF to the printer. Obviously there are all kinds of things that go wrong here. Without checked exceptions, I'm going to end up with something like:
try { payrollSystem.printPaycheck(emp);
} catch(Exception e) {
// show a dialog box indicating things went wrong
}
Why? Because I have no idea what exceptions are being thrown by printPaycheck() and no way to find out. But if I have checked exceptions I can do something more user-friendly:
try { payrollSystem.printPaycheck(emp);
} catch(DatabaseException e) {
// let the user know the database appears to be offline and they should try again later
} catch(NetworkException e) {
// let the user know there was an issue connecting to the network
} catch(PrintException) {
// let the user know there was a problem printing, maybe the printer is offline or needs paper?
}
Further, within printPaycheck(), if I get a DatabaseException I might want to try again, or try connecting to the backup database. But to do that I need the database driver to give me some kind of hint -- did I get a timeout while connecting, or could the URL of the database not be resolved?
Summary: without checked exceptions, I just have to guess at what might have gone wrong. With checked exceptions, I have a decent idea of the type of problem that occurred, and that gives me options in handling it.
Thomas