Exception Handling in C# - Separation of Concerns

(Page 2 of 8 )

The fundamental thing that exceptions allow you to do is to separate the essential functionality from the error handling. In other words, we can rewrite the mess above like this:


...
public sealed class PainLess
{    
    public static int Main(string[] args)
    {
        try
        {
           string filename = args[0];
           char[] source = ReadSource(filename);
           Process(filename, source);
           return 0;
        }
        catch (SecurityException    caught) { ... }
        catch (IOException          caught) { ... }
        catch (OutOfMemoryException caught) { ... }
        ...
    }
    private static char[] ReadSource(string filename)
    {
        FileInfo file = new FileInfo(filename);
        int length = (int)file.Length;
        char[] source = new char[length];
        TextReader reader = file.OpenText();
        reader.Read(source, 0, length);
        reader.Close();
        return source;
    }
}



There are several things to notice about this transformation.

1. The numeric integer error codes that utterly failed to describe the errors they represented (e.g. what does 2342 mean?) are now descriptively named exception classes (e.g. SecurityException).
   
   
2. The exception classes are not tightly coupled to each other. In contrast, each integer code must hold a unique value thus coupling all the error codes together.
   
   
3. There is no throw specification on ReadSource. C# does not have throw specifications.

However, by far and away the most important thing to notice is how much cleaner, simpler and easier to understand ReadSource has become. It now contains only the statements required to implement its essential functionality. It makes no apparent concession to error handling. This is possible because if an exception occurs, the call stack will unwind all by itself. This version of ReadSource is the "ideal" we are aiming it. It is as direct as we can make it.

Ironically, exceptions allow us to get close to this ideal version of ReadSource but at the same time prevent us from quite reaching it. ReadSource is an example of code that acquires a resource (a TextReader), uses the resource (Read), and then releases the resource (Close). The problem is that if an exception occurs after acquiring the resource but before releasing it then the release will not take place. The solution has become part of the context. Nevertheless, this ideal version of ReadSource is useful; we can compare forthcoming versions of ReadSource to it as a crude estimate of their idealness.

Next: The Solution, but More Issues >>
 

More C# Articles
More By Jon Jagger

Comments On: Exception Handling in C#

>>> Be the FIRST to comment on this article!