MSDN Magazine - February 2009 - (Page 21)

happened. For example, consider a program that calls ficult to write correct code that handles a CSE and con[HPCSE] native code that’s known to be buggy. Debugging into tinues running the process safely. fn1() { the code you learn that it sometimes zeros a pointer beLook closely at the code in Figure 4 to see what could try {} fore accessing it, which causes an access violation. You go wrong. If this code is not in a function that can procatch(){} } might want to use the HandleProcessCorruptedStatecess CSEs, then the finally block will not run when an Exceptions attribute on the function which calls native access violation happens. That’s fine if the process tercode using P/Invoke because you know the cause of the minates—the open file handle will be released. But if fn2() pointer corruption and are comfortable that the process some other code catches the access violation and tries integrity is maintained. to restore state, it needs to know that it has to close this The other scenario that may call for the use of this atfile as well as restore any other external state this profn3() { tribute is when you’re as far as you can be from the error. gram has changed. try {} nally {} In fact, you’re almost ready to exit your process. Say you’ve If you decide that you’re going to handle a CSE, your } written a host or a framework that wants to perform some code needs to expect that there is a ton of critical state custom logging in case of an error. You might wrap your that has not been unwound. Finally and fault blocks have main function with a try/catch/finally block and mark fn4() { not been run. Constrained execution regions have not it with HandleProcessCorruptedStateExceptions. If an been executed. The program—and the process—are in Access Violation! error unexpectedly makes it all the way up to your pro- } an unknown state. gram’s main function, you write some data to your log, If you know your code will do the right thing, then doing as little work as you have to, and exit the process. Figure 3 Excepyou know what to do. But if you’re not sure of the state When the integrity of the process is in question any work tion and Access your program is executing in, then it’s better to just let you do could be dangerous, but if the custom logging fails Violation your process exit. Or, if your application is hosted, insometimes it’s acceptable. voke the escalation policy your host Take a look at the diagram shown Figure 4 The Finally Block May Not Run has specified. See Alessandro Catorcini in Figure 3. Here function 1 (fn1()) void ReadFile(int index) and Brian Grunkemeyer’s CLR Inside { is attributed with [HandleProcessOut column from December 2007 at System.IO.StreamReader file = CorruptedStateExceptions] so its catch msdn.microsoft.com/magazine/cc163298 for new System.IO.StreamReader(filepath); try clause catches the access violation. The more information on writing reliable { finally block in function 3 does not excode and CERs. file.ReadBlock(buffer, index, buffer.Length); } ecute even though the exception will catch (System.IO.IOException e) be caught in function 1. Function 4 at Code Wisely { Console.WriteLine("File Read Error!"); the bottom of the stack raises an acEven though the CLR prevents you } cess violation. from naively catching CSEs, it’s still finally { There is no guarantee in either of not a good idea to catch overly broad if (file != null) these scenarios that what you’re doclasses of exceptions. But catch (Excep{ file.Close() ing is completely safe, but there are tion e) appears in a lot of code, and it’s } scenarios where just terminating the unlikely that this will change. By not } } delivering exceptions that represent process is unacceptable. However, if you decide to handle a CSE there is a a corrupted process state to code that huge burden on you as the programmer to do it correctly. Remem- naively catches all exceptions, you prevent this code from making ber that the CLR exception system won’t even deliver a CSE to any a serious situation worse. function that is not marked with the new attribute either during The next time you write or maintain code that catches an exception, the first pass (when it searches for a matching catch clause) or the think about what the exception means. Does the type you caught second pass (when it unwinds each frame’s state and executes fi- match what your program (and the libraries it uses) is documented nally and fault blocks). to throw? Do you know how to handle the exception such that your The finally block exists in order to guarantee that code always program can correctly and safely continue execution? runs, whether or not there is an exception. (Fault blocks run only Exception handling is a powerful tool that should be used carewhen an exception occurs, but they have a similar guarantee of fully and thoughtfully. If you really need to use this feature—if you always being executed.) These constructs are used to clean up really need to handle exceptions that may indicate a corrupt procritical resources such as releasing file handles or reversing im- cess—the CLR will trust you and let you do so. Just be careful and personation contexts. do it correctly.  Even code that is written to be reliable through the use of constrained execution regions (CER) won’t be executed when a CSE Andrew PArdoe is a program manager for CLR at Microsoft. He works on many has been raised unless it is in a function that has been marked with aspects of the execution engine for both the desktop and Silverlight runtimes. He the HandleProcessCorruptedStateExceptions attribute. It’s very dif- can be reached at Andrew.Pardoe@microsoft.com. msdnmagazine.com February 2009 21 http://msdn.microsoft.com/magazine/cc163298 http://www.msdnmagazine.com

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.