4 ms·

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

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.

TazeTSchnitzel 14y ago
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.
- AndrewDucker 14y ago
  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).
- freeman478 14y ago
  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).
- nknight 14y ago
  > 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.
  - DuncanMak 14y ago
    In that case, why don't you just put 'throws Exception' on all your methods?
    - nknight 14y ago
      I said "theoretically", did I not? 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.
sixcorners 14y ago
Attributes? Why not just throw new RuntimeException(exception); Edit: If there weren't exceptions for every mundane thing I think I would prefer no checked exceptions also.
- slavak 14y ago
  Because you've in essence bypassed the entire checked-exception system anyway?
  - sixcorners 14y ago
    How? You acknowledged that the exception exists. You didn't do that by putting 'throws' on everything.
thebluesky 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. 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)

TazeTSchnitzel 14y ago

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.

AndrewDucker 14y ago
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).
freeman478 14y ago
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).
nknight 14y ago
> 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.
- DuncanMak 14y ago
  In that case, why don't you just put 'throws Exception' on all your methods?
  - nknight 14y ago
    I said "theoretically", did I not? 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.

sixcorners 14y ago

Attributes? Why not just throw new RuntimeException(exception); Edit: If there weren't exceptions for every mundane thing I think I would prefer no checked exceptions also.

slavak 14y ago
Because you've in essence bypassed the entire checked-exception system anyway?
- sixcorners 14y ago
  How? You acknowledged that the exception exists. You didn't do that by putting 'throws' on everything.

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