Back to Basics: Exception Handling

Rick G. Garibay - The more I learn, the less I kno — Wed, 07 Nov 2007 16:47:10 GMT

The .NET Framework is vast, and there are many aspects of the framework that are used every day by developers while others start to collect dust on the knowledge shelf.

I consider myself a generalizing specialist, which in short means that when it comes to .NET, I've been there and done that, but I am currently focused on middle-tier and SOA architecture, design and development. From time to time, I find myself having to shake the cobwebs loose on some pretty fundamental features in the framework, so I am going to start up a new post category called "Back to Basics" to help new and seasoned folks alike (not to mention to document this stuff so I can look it up again later when I forget again).

Recently, I found myself pondering exception handling behavior with custom exceptions. Fortunately, I hit my friend and collegue John Bierman, a Senior Consultant from Neudesic up and he set me straight:

If you catch a custom exception in a generic exception catch block in a middle tier component – i.e. catch(Exception ex) – and then:

· Issue the “throw” command, the exception will be propagated to the preceding method call as the custom exception…you will not lose the fact that it’s a custom exception and you will keep the original stack trace of the custom exception.

· Issue the “throw ex” command, the exception will be propagated to the preceding method call as the custom exception… you will not lose the fact that it’s a custom exception *but* you will lose the original stack trace. The new stack trace will look as though the exception originated from the location that issued the “throw ex”.

· Issue the “throw new Exception(ex.message, ex.innerException)” command, the exception will *not* be propagated to the preceding method call as the custom exception, its type will be a generic Exception… you *will* lose the fact that it’s a custom exception.

Good stuff!