Is C# missing checked exceptions?

An interesting thread on SlashDot asks if a developer should learn C# or Java as a 2nd year student.  In typical SlashDot form, there are the usual uneducated anti-MS bashing comments on missing features that actually exist or comparisons of features where the author is clearly stretching to find something where the Java language excels over C#.  One such case is checked exceptions, which first surfaces in the comments thread here.  In more typical SlashDot form, the original question becomes hopelessly lost in a debate over the merits of checked exceptions and their utility.  I like to scroll to the bottom of the thread and read from the bottom up, trying to guess what the original subject might have been.

The real question is if C# is missing checked exceptions or not.  No, I am not asking if it is possible to implement them in C# or not, I am asking if this is a feature that should have been included at all and if it is a killer feature.  Given the arguments against checked exceptions that I have read so far by folks like Bruce Eckel and Anders Hejlsberg, I pretty convinced that the omission of checked exceptions was a good thing.

 

 

 

 

Comments

• Anonymous
  December 24, 2005
  Well. If "checked exceptions" is feature that should NOT never be included - then MSFT have not spend time on research like this:
  
  http://research.microsoft.com/specsharp/papers/krml135.pdf
  http://research.microsoft.com/~leino/papers/Leino-CASSIS2004.ppt
  
• Anonymous
  December 24, 2005
  The same thing occured to me sometime back (8 days to be exact :) ) and I blogged about it. Take a look in http://blogs.msdn.com/abhinaba/archive/2005/12/16/504373.aspx
• Anonymous
  December 24, 2005
  The comment has been removed
• Anonymous
  December 26, 2005
  Checked exceptions in the current implementation simply needs some more thought to come up with a different solution. It's a nice feature at first glance, and I agree with Keith that it provides a level of exception analysis to the developer. However, you have to think about Anders' and Bruce Eckel's points about checked exceptions causing an increase in the amount of swallowed exceptions. This is a pretty strong code smell caused by the language itself.
  
  Admittedly, I have a pretty strong view on proper exception handling and the fact that most developers don't think twice about catching and swallowing System.Exception types:
  
  xmladvice.com/blogs/kaevans/archive/2004/02/04/5930.aspx
  xmladvice.com/blogs/kaevans/archive/2004/02/18/5937.aspx
  
  I think Keith raises an interesting question, whether this should be a compilation warning or error. Warnings should be treated as errors (flip that bit in the project settings), so there is no real difference. Perhaps instead of forcing warning or error, there could be an assembly attribute or a pragma switch to indicate suppression at compile time (and give the VB.NET folks another Option statement to achieve the same). Make it off by default to preserve backwards compatibility.
  
  However, reams and reams of C# code has been written without checked exceptions being a major missing feature, and you have to think if the inclusion of checked exceptions would increase or decrease code quality, performance, and maintainability. I am not convinced that this is a feature that would yield enough return to justify the investment and most programmers would happily ignore its inclusion if the feature were made optional.
• Anonymous
  January 03, 2006
  The comment has been removed