I am _very_ glad that C# does not have checked exceptions. Anders is completely correct in that the vast majority of the time individual methods do not handle specific exceptions, they just roll things back and pass the exception up the way. Adding exception attributes in all of these places would be a massive pain.
In my experience many C# programmers simply fail to add much exception handling code at all because the compiler doesn't force them to. The net result is code which breaks in spectacular fashion when the first unexpected condition is met.
Checked exceptions are a nuisance (I'm actually glad Scala doesn't enforce them vs Java), but often leads to inexperienced C# devs writing very fragile apps.
With C# you have to examine docs and source to identify exceptions which could be thrown. Many programmers don't bother, leading to things breaking. In Java the compiler forces you to think about it. I'm not in favour of checked exceptions, but the arguments against them tend to be a bit simplistic.
The net result is code which breaks in spectacular fashion when the first unexpected condition is met.
Which is generally what you want to have happen. Failing fast is a good thing. If your code does anything other than "stop executing" after encountering an exceptional situation, it should be very something carefully considered and well-thought-out. With checked exceptions, the "I'm in a hurry to get this working" version of the code often ends up looking a lot like:
try {...}
catch(ExceptionType ex){ //TODO figure out what to do here }
... keep going ...
The danger is what happens in that "... keep going ..." section - the code is working under faulty assumptions and that can lead to a lot of non-obvious but horrific bugs. In the unchecked "I'm in a hurry" version, the program simply crashes at that point.
So I think the C# design choice leads to the least pain under bad conditions. I'd rather have a fragile application than one just robust enough to write bad data to my database.
That said, it's not perfect. Any sufficiently lazy/stupid programmer can write the equivalent of "On Error Resume Next" in any language.
> In my experience many C# programmers simply fail to add much exception handling code at all because the compiler doesn't force them to.
Still better than:
try {
// Do broken stuff
} catch (Exception e) {
throw new RuntimeException(e); // TODO: Add a domain-specific runtime exception so we can actually catch this
}
I find this or something like it[0] spread across every Java codebase I find myself mired in, and I read a lot of Java these days (much to my dismay, but so it goes).
[0]: Actually, that's not fair. Most people don't bother to include the TODO.
You meant to say "catch (Throwable e)", right? But, yeah, I've had to write that block too many times.
Throwable will catch Errors as well as Exceptions, such as when a constructor called from a dependency injection framework fails. It's kind of irked me for a while that I had to know that. I would have rather had "catch" work on anything, with the option to check the class and rethrow once in a great while. That is, in the few places where the error checking/logging actually belongs (as stated in the article, with which I obviously agree).
There is indeed great irony in Java code littered with catches, which then falls out and kills the main loop without logging anything. (I recently had to diagnose such a case in a system at work over the phone -- sure enough, that's exactly what was coded)
You are not supposed to, and don't need to, catch Errors. The only exceptions you need to worry about as far as checked exceptions go are classes that inherit from Exception but not RuntimeException.
I kind of agree that Java's approach forces people to think about error handling. But really that's it's only virtue. Once people do think about error handling in their program, the best approach almost inevitably involves subverting the checked exception feature.
The reality is that programmers do not have the time to handle every single possible exception. I reckon every few function calls you make could potentially trigger an exception. You generally just have a catchall (or not, and let the program abort), and then catch certain specific exceptions that are common enough.
Yes unchecked exceptions are nice. However it would be nice if the compiler could enforce documentation of possible exceptions raised by a method. Something like the throws keyword of Java with unchecked exceptions.
That way you (through the IDE) could know at any point of your code what exceptions could happen (and not have to guess or go through all the called code to identify them).
Absolutely. I handle the ones that are common enough to be worth investing time in (or have severe enough consequences). The rest recover as best they can and tell the user "Something bad happened. Call the helpdesk." (while logging a stacktrace).
> I reckon every few function calls you make could potentially trigger an exception.
One Java module I had the misfortune of writing theoretically had to deal with checked exceptions on the majority of its calls, and the only possible response to virtually all of them was to crash, because in that context, it could only have meant someone had either ripped the DRAM off the board, or placed the board in a particle accelerator.
And there was nothing particularly special about the module aside from the extreme concentration. Every piece of Java I've ever written or even looked at has this same problem on a reduced scale.
My point is to show how utterly broken and worthless the concept is. Either there's a ton of exception-"handling" boilerplate that does nothing useful, or there's "throws Exception" everywhere, itself useless boilerplate that exists only to tell the compiler to buzz off.
