Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » Exception Handling   (RSS)

The good and the bad of exception filters

Every so often we get asked questions about the CLR’s support for exception filters. Why do some languages support them and others do not? Is it a good idea to add them to my new language? When should I use a filter vs. catch/rethrow? Etc. I’ll try to

Getting more information than the exception class provides

We recently had a question about how to get more information than an exception’s type provides. The developer was trying to copy a file and didn’t know why the copy was failing. File copies can fail for many reasons, almost all of them what Eric Lippert

How CLR maps SEH exceptions to managed exception types

Managed exception handling is built on Windows OS’s Structured Exception Handling , commonly referred to as SEH (to learn more about SEH, please read Matt Pietrek’s excellent article first). This implies that CLR understands how to interoperate between

ThreadAbortException

System.Threading.ThreadAbortException is just plain weird. For instance, most exceptions happen because of something code did on its own thread: even asynchronous exceptions are caused by something your code did on the current thread. (Note for the nitpickers:

Exceptions out of Fault/Finally

Assumption: This write-up assumes that you are familiar with the managed exception handling constructs (e.g. catch, filter, fault, finally). If not, you may want to read this and also refer to the CLI specification . Managed exception handling exposes

Why catch(Exception)/empty catch is bad

You’ve seen the advice before— it’s not a good programming practice to catch System.Exception . Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions.

Catch, Rethrow and Filters - Why you should care?

A very common pattern in the usage of managed exception handling is that of catching an exception, inspecting it's type and rethrowing it once you realize it was not the exception you wanted to handle. Below is such an example (and should be avoided in
 
Page view tracker