Throwing Exceptions

Application error handling can take significant amounts of code. Common practice in many programming languages is to train developers to centralize the error-handling code in one location and automatically go to that code to handle any error conditions. The error-handling code then determines what has gone wrong and deals with it so that the application can resume. At the broadest level, the large amounts of code required to account for many different error conditions when little contextual information is available can be cumbersome and verbose. Beyond that, the error constructs that move execution to the central error-processing code is not as efficient as the try-catch construct. A try- catch can be a more efficient means for dealing locally with exceptional conditions in cases where some context to the possible problems is more readily available.

Throwing and catching exceptions still adds a cost to error management. I recently saw an example illustrating the advantages of try-catch in which the problem was a divide-by-zero error. Even though catching a divide-by-zero error might be simpler than deferring to global error-handling code, checking for problems in code without a try-catch block is actually far more efficient. Remember, however, that an exception is generally used for exceptional conditions. Why pay the performance price of throwing exceptions when simple parameter validation will suffice?

Code Listing 9-3 shows the use of the try-catch construct to handle the case in which the divisor is not valid. In this code, suppose the invalid value comes from user input, not because it is hardcoded. In such a case, it is an error and not really an exceptional condition, so we are using exceptions for error detection. Code Listing 9-4 replaces the try-catch with a simple if-statement to check for the condition and handles the problem in the same way, that is, with a Response.Write. Although the try-catch is better than the alternatives such as using a simple throw, specific error checks are a better programming practice and can lead to improved performance in many circumstances.

Code Listing 9-3: DivideByZeroWithException.aspx

 <script language="C#" runat="server">
protected void Page_Load(object o, EventArgs e) {
    try {
        int x;
        int y;
        x = 5;
        y = 0;
        int result = x / y;
        string message = "result is: " + result;
        Response.Write(message);
    }
    catch(DivideByZeroException) {
        Response.Write("divisor can't be zero");
    }
}
</script> 

Code Listing 9-4: DivideByZeroWithChecking.aspx

 <script language="C#" runat="server">
protected void Page_Load(object o, EventArgs e) {
    int x;
    int y;
    x = 5;
    y = 0;
    if(y != 0) {
        int result = x / y;
        string message = "result is: " + result;
        Response.Write(message);
    }
    else {
        Response.Write("divisor can't be zero");
    }
}
</script> 

The overhead of throwing exceptions will probably not be a major factor in most cases, but the accumulated effects of throwing many exceptions can add up. Also, using exceptions instead of handling normal conditions in code, such as with simple statements, might be unnecessary and can lead to overall difficulties in maintaining code. Avoiding unnecessary exceptions is a coding practice that is better for performance and readability.