Exceptions

Since I come from a Java background, there was a bit of adjustment to .NET Framework approach to Exception handling.

The biggest difference between Java and .NET Exception Handling:

Java has checked exceptions, .NET does not have checked exceptions

No checked exceptions = no "throws" keyword, and no "throws" on method signatures.

Checked exceptions in Java always made me feel "boxed in" when I was programming, and made me spend a lot of time on "scaffolding" code.

This difference took me a bit of adjustment time. However, I found that I preferred the .NET approach to exception handling. I always hated working with APIs or Frameworks where the infrastructure code threw a lot of Exceptions, so I was forced to have huge try-catch blocks, and I wasn't really sure what to do in the event of an Exception.

A classic example is working with just about any class in the java.io or java.nio packages.

Back to Exceptions in .NET ... I often refer to the following section of MSDN Website:

Best Practices for Handling Exceptions

Notes about Exception handling:

• System.Exception is the root class for all Exceptions. System.SystemException and System.ApplicationException derive from System.Exception.


• Initially, I thought that all custom application exceptions should derive from System.ApplicationException (hence the name). However, the best practices on MSDN suggest that this is not necessarily true.