C# and checked exceptions

Ever since I was at university, I've had an interest in compilers and compiler theory. When I was in third year, we were given a course called Comparative Programming Languages by Gary Marsden, which caused me to be interested in the evaluation of programming languages as well.

We looked at various programming languages and evaluated then according to various criteria. The temptation would be to evaluate them according to language features (like this website did), but we chose to evaluate them according to more subtle principles like readability, maintainability and learnability (like this website did).

One of the principles that I really insist on is error prevention. By this I mean that the language and its compiler must fail a compilation if a commonly known error condition exists. In other word, a compiler will behave in a way emulating the fail fast  principle. Features such as type safety achieve this goal to some extent.

Consider a language such as C++. How many times have you been caught out by a code snippet like this one?

if(foo = 0)
{
    
// Dead code
}

What is going on here? What did we intend to do here? We wanted to test whether foo is 0, but this is not what is happening, because we used the assignment operator instead of the equality operator. The variable foo is being assigned to 0, and then the value of foo is being passed on to be evaluated as the predicate of the if statement. The result is that that the predicate of the if statement always evaluates to false, resulting in dead code inside of the if statement block.

In languages such as C# and Java you will not be able to compile code like that. The designers of the C# and Java languages have recognised that this is a common error condition and have prevented it from happening. They did this by insisting that predicates of if statements evaluate to boolean expressions. This is what a type safe language does, and it prevents errors by failing the compilation step, resulting in more robust applications.

Now there is a feature in Java that I am missing in C#. This feature is known as checked exception handling . Checked exception handling is a feature of the Java programming language where exceptions must either be handled or methods that bubble exceptions up the stack must declare that they intend to do so. Here is an excerpt from the Java Language Specification concerning checked exceptions:

A compiler for the Java programming language checks, at compile time, that a program contains handlers for checked exceptions, by analyzing which checked exceptions can result from execution of a method or constructor. For each checked exception which is a possible result, the throws clause for the method (§8.4.4) or constructor (§8.8.4) must mention the class of that exception or one of the superclasses of the class of that exception. This compile-time checking for the presence of exception handlers is designed to reduce the number of exceptions which are not properly handled.

Checked exception handling is a feature that has attracted many opponents, but I think that checked exceptions do increase the quality of code by forcing the developer to think about whether or not an exception should be handled, or it would force the developer to think about how an exception should be handled. I've seen software being deployed where an exception was not thought about, and it costs the sponsoring company a lot of money.

powered by IMHO 1.3

Published Thursday, April 13, 2006 11:22 PM by trumpi
Filed under:

Comments

# re: C# and checked exceptions

>>but I think that checked exceptions do increase the quality of code by forcing the developer to think about whether or not an exception should be handled<<

I'm not sure about that. My gut feeling is that Checked or Unchecked, developers will ignore them anyway. It's probably just more annoying to do so in Java :-)

Friday, April 14, 2006 11:36 PM by Senkwe

# re: C# and checked exceptions

Having used java extensively, I can see the logic of the "unchecked camp". Constantly having to catch the exception in a context where it is not appropriate to deal with it elegantly is an overhead I could do without. However, were I to start coding in C# it would take me a long time get get used to unchecked exceptions and it would probably irritate me.

However, one of the show stoppers of unchecked exceptions IMO, is that the calling context has _no_ idea what exceptions are actually thrown and there is no way to enforce that this information is exposed!

I agree with your reference to "forcing the developer to think about whether or not an exception should be handled" - the unchecked camp points out how often they have seen "blank" (shock and horror it does happen), catch clauses - at least in Java you can blame some developer for _choosing_ to ignore the exception by putting this blank catch clause in. With modern IDE's you can format the catch clause to _always_ log the exception.

Wednesday, April 19, 2006 12:38 PM by Michael Wiles

# re: C# and checked exceptions

@Senkwe:

You make a very good point, and many Java Developers are practicing a coding style known as exception abuse. Typical behaviour here is things such as catching Exception and logging it, or just declaring that the method throws Exception.

This sort of abuse can occur in C# as well. Two examples that I can think of is ignoring compiler warnings and supressing all static analysis violations.

So at the end of the day, it is up to the developer to use the features of the compiler to write reliable code.

Wednesday, April 19, 2006 5:04 PM by trumpi

# C# and checked exceptions

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Monday, September 25, 2006 8:11 PM by DotNetKicks.com