Kirk Evans Blog

.NET From a Markup Perspective

Is C# missing checked exceptions?

Is C# missing checked exceptions?

  • Comments 5

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.

 

 

 

 

 

  • 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
  • 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
  • There are two parts of the argument, though:

    * Checking whether exceptions are being caught
    * What to do about it

    I don't think anybody can argue that its bad to check to see whether there are exceptions that aren't being caught. The argument really is whether this should be a compilation error.

    I agree with Anders's argument that a compilation error leads to problems down the line. However, a compilation *warning* suffers no such problems, and provides the benefits of the exception analysis to the developer.
  • 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.
  • I suppose checked exceptions *can* be good, although I could live with or without them. The Spec# paper certainly touts checked exceptions as a Good Thing (tm).

    I wonder if perhaps the issue could be solved in a very simple way: with a compiler switch.

    Want checked exceptions? Check a checkbox in the compiler properties page -- or manually type in "-checkExceptions" or whatever in the command line if you're "manly". Then the compiler generates errors and/or warnings for uncaught exceptions. Don't want 'em? Don't check the box.

    'Course, you might need to add a throws keyword, but you could always have the compiler read the "exception" XML comment tags.

    Then both sides of the issue are happy. :)
Page 1 of 1 (5 items)
Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives