4 ms·

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 w

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.

paol 14y ago
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.
jsolson 14y ago
> 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.
- Roboprog 14y ago
  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)
  - sixcorners 14y ago
    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.
hartez 14y ago
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.

paol 14y ago

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.

jsolson 14y ago

> 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.

Roboprog 14y ago
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)
- sixcorners 14y ago
  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.

hartez 14y ago

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.