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.