MSDN Magazine - February 2009 - (Page 15)

AndrEw PArdoE CLR InsIde Out Handling Corrupted State Exceptions Have you ever written code that isn’t quite right but is close enough? Have you had to write code that works fine when everything goes well, but you’re not quite sure what will happen when something goes wrong? There’s a simple, incorrect statement that’s probably sitting in some code that you wrote or have had to maintain: catch (Exception e). It seems innocent and straightforward, but this little statement can cause a lot of problems when it fails to do what you expect. If you’ve ever seen code that uses exceptions the way the following code does, then you need to read this column: Program code (or the library code it uses) can throw types derived from System.Exception, the CLR execution engine can raise exceptions, and unmanaged code can raise exceptions as well. Exceptions raised on a thread of execution follow the thread through One() fn1() native and managed code, across AppDomains, and, if not handled by the program, are treated as unhandled exceptions by the operating system. Two() fn2() An exception indicates that something bad has happened. While every managed exception has a type (such as System.ArgumentException fn3() Oops() or System.ArithmeticException), the type is only meaningful in the context in which the exception public void FileSave(String name) is raised. A program can handle an exception if it { fn4() understands the conditions that caused the exceptry CLR Process tion to occur. But if the program doesn’t handle { FileStream fs = new FileStream(name, FileMode.Create); the exception, it could indicate any number of bad Program Flow } things. And once the exception has left the program, catch (Exception) Exception { Unwind it only has one very general meaning: something throw new System.IO.IOException(“File Open Error!”); bad has happened. } } Figure 1 One Thread’s When Windows sees that a program doesn’t hanThe error in this code is common: it is simpler to Unhandled Exception dle an exception, it tries to protect the program’s write code to catch all exceptions than it is to catch Causes the Entire Process persisted data (files on disk, registry settings, and to Terminate exactly the exceptions that could be raised by code so on) by terminating the process. Even if the exexecuting in your try block. But by catching the base of the excep- ception originally indicated some benign, unexpected program tion hierarchy, you will end up swallowing an exception of any type state (such as failing to pop from an empty stack) it appears to be a and converting it to an IOException. serious problem when Windows sees it because the operating sysException handling is one of those areas about which most tem doesn’t have the context to properly interpret the exception. A people have a working knowledge rather than an intimate under- single thread in one AppDomain can bring down an entire CLR standing. I’ll begin with a bit of background information explain- instance by not handling an exception (see Figure 1). ing exception handling from the CLR point of view for those who If exceptions are so dangerous, why are they so popular? Like may be more familiar with exception handling from native pro- motorcycles and chain saws, the raw power of exceptions makes gramming or an old college textbook. If you’re an old pro at man- them very useful. Normal dataflow on a program thread goes from aged exception handling, feel free to skip ahead to the section on function to function through calls and returns. Every call to a funcdifferent kinds of exceptions or the one on managed code and tion creates a frame of execution on the stack; every return destroys structured exception handling (SEH). Make sure to read the last that frame. Aside from altering global state, the only flow of data in few sections, though. a program is achieved by passing data between contiguous frames Windows terminates CLR process due to unhandled exception What Exactly Are Exceptions? An exception is the signal raised when a condition is detected that was not expected in the normal execution of a program thread. Many agents can detect incorrect conditions and raise exceptions. This column is based on a prerelease version of Visual Studio 2010. All information is subject to change. Send your questions and comments to clrinout@microsoft.com. February 2009 15

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.