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!