Exception Handling Series – Part I

Overview

Exception handling can be compared with car accidents. As we human are prone to accidents so as applications are. No matter how good the driver, or how well designed the vehicle, accidents are part of driving experience. The same applies to software applications. We have good applications, like good vehicles, we can prepare a mechanism to deal with failures; and if we cannot avoid failures completely then we can at least control them. A vehicle’s crumple zone is a good example.

Car Crash

Car Crash

The main idea of the vehicle crumple zone is to reduce the rate of acceleration experienced by the occupants, increase survivability, reduce the likelihood the occupants will be seriously hurt, transform non deterministic event into a deterministic event so that forces of an accident can be controlled to a greater or lesser extent. Exception Handling should be viewed in the same manner.

Exception Handling:

•  Increases safety of the application (the vehicle)

•  Increases survivability of data (the occupant)

•  Protects data from being thrown out of the vehicle

•  Transforms a non deterministic event (random software error) into a controlled event.

Exception Handling is the crumple zone of an application and must be considered during the application’s design and implementation. Retro-fitting Exception Handling in an application makes about as much sense as installing an after-market crumple zone.

Type-based Errors


Exception handling in the .NET Framework is fairly simple. As in traditional ASP where Exception Handling was limited, but on the other hand ASP.NET provides an Exception Handling mechanism which extends from method to top most application layer.
Instead of displaying arcane and cryptic error codes to user, .NET provides a type-based error handling. Now by this exceptional events are identified by their type (such as NullReferenceException or OverflowException).
Import question in this entire post is

Q: What is an exception?

A: An exception is a violation of an implicit assumption.

In regards to software applications, the implicit assumption is that resources (like files, database connections, etc) should be available and that objects should be properly created and populated. Of course, there are many more assumptions possible.

Exception handling in .NET is expensive; that is, the Runtime will execute a stack walk, starting with the location where the exception occurred. If a handler is not found, the CLR continues its stack walk, investigating whether each method in the call stack implements a handler. Ouch. 

It is best to avoid invoking the Exception Handling mechanism when possible by simply testing for appropriate values. Instead of implementing arcane and cryptic error codes, .NET implements a type-based error facility. Exceptional events are identified by their type.

The System.Exception class is the base class for all exceptions. At least two categories of derived classes exist

•  The System.SystemException class, which serves as the class from which most of the pre-defined Runtime exception classes derive.

•  The System.ApplicationException class, which is intended for user-defined exceptions specific to a given application.

The Framework’s exception types support the following features:

•  Human-readable text that describes the error via the Exception.Message property.

•  The state of the call stack when the exception was thrown via the Exception.StackTrace property. The StackTrace property carries a stack trace that can be used to determine the location of the error. The stack trace lists all the called methods and the line numbers in the source file where the calls are made.

Unhandled Exceptions

If exception handling is not implemented then it becomes very expensive. Whenever any exception occurs, the .NET Framework Runtime starts looking for exception handler, it starts from the location where exception occurred.

unhandled exception

Unhandled exception - Image directly from SANS slides

If it does not found any handlers, then the CLR starts walk that will continue until a handler is found. In this lengthier walk CLR checks for each method on the calling stack to determine whether any exception handler exists. If CLR does not finds any exception handler in the last calling method in the stack, then that exception is considered as unhandled and the CLR terminates the application.

Reference

http://www.sans.org/security-training/essential-secure-coding-aspnet-1502-mid

Type-based Errors

Exception Handling in the .NET Framework is an elegant affair. Unlike, traditional ASP where Exception Handling could only be implemented at the method level, ASP.NET provides an Exception Handling architecture extending from the method all the way to the top most application layer.

Instead of implementing arcane and cryptic error codes, .NET implements a type-based error facility. Exceptional events are identified by their type (such as NullReferenceException or OverflowException).

What is an exception? An exception is a violation of an implicit assumption. In regard to vehicular traffic, the implicit assumption is that drivers will want to avoid accidents. An accident represents a violation of the implicit assumption. The crumple zone represents the architecture for handling such a violation.

In regards to software applications, the implicit assumption is that resources (like files, database connections, etc) should be available and that objects should be properly created and populated. Of course, there are many more assumptions possible.

Exception handling in .NET is expensive; that is, the Runtime will execute a stack walk, starting with the location where the exception occurred. If a handler is not found, the CLR continues its stack walk, investigating whether each method in the call stack implements a handler. Ouch.

It is best to avoid invoking the Exception Handling mechanism when possible by simply testing for appropriate values. Instead of implementing arcane and cryptic error codes, .NET implements a type-based error facility. Exceptional events are identified by their type.

The System.Exception class is the base class for all exceptions. At least two categories of derived classes exist

•  The System.SystemException class, which serves as the class from which most of the pre-defined Runtime exception classes derive.

•  The System.ApplicationException class, which is intended for user-defined exceptions specific to a given application.

The Framework’s exception types support the following features:

•  Human-readable text that describes the error via the Exception.Message property.

•  The state of the call stack when the exception was thrown via the Exception.StackTrace property. The StackTrace property carries a stack trace that can be used to determine the location of the error. The stack trace lists all the called methods and the line numbers in the source file where the calls are made.

Posted in ASP.NET, Programming Language, Secure .NET Coding, Security