MSDN Magazine - February 2009 - (Page 17)

was raised. Using error codes requires the programmer to inspect and pass on an error code at every stack frame until it reaches the place where the erroneous condition can be handled. Exception handling frees the programmer from inspecting the exception at every frame on the stack. For more on throwing custom exception types, see “Error Handling: Throwing Custom Exception Types from a Managed COM+ Server Application” at msdn.microsoft.com/magazine/cc188737. Win32 SEH Exceptions and System.Exception There’s an interesting side effect that comes from the ability to catch exceptions far away from where the exception was raised. A program thread can receive program exceptions from any active frame on its call stack without knowing where the exception was raised. But exceptions don’t always represent an error condition that the program detects: a program thread can also cause an exception outside of the program. If a thread’s execution causes a processor to fault, then control is transferred to the operating system kernel, which presents the fault to the thread as an SEH exception. Just as your catch block doesn’t know where on the thread’s stack an exception was raised, it doesn’t need to know exactly at what point the OS kernel raised the SEH exception. Windows notifies program threads about OS exceptions using SEH. Managed code programmers will rarely see these because the CLR typically prevents the kinds of errors indicated by SEH exceptions. But if Windows raises an SEH exception, the CLR will deliver it to managed code. Although SEH exceptions in managed code are rare, unsafe managed code can generate a STATUS_ACCESS_ VIOLATION which indicates that the program has attempted to access invalid memory. For details on SEH, see Matt Pietrek’s article “A Crash Course on the Depths of Win32 Structured Exception Handling” in the January 1997 issue of Microsoft Systems Journal at microsoft.com/msj/0197/ exception/exception.aspx. lack of memory, but a correct program using well-written libraries shouldn’t be expected to deal with an access violation. This separation is useful for programmers. An AV is a serious problem: an unexpected write to critical system memory can affect any part of the process unpredictably. But some SEH errors, such as a divide-by-zero error resulting from bad (and unchecked) user input, are less serious. While a program with a divide-by-zero is incorrect, it’s unlikely that this will affect any other part of the system. In fact, it’s likely that a C++ program could handle a divideby-zero error without destabilizing the rest of the system. So while this separation is useful, it doesn’t quite express the semantics managed programmers need. Managed Code and SEH The CLR has always delivered SEH exceptions to managed code using the same mechanisms as exceptions raised by the program itself. This isn’t a problem as long as code doesn’t attempt to handle exceptional conditions that it cannot reasonably handle. Most programs cannot safely continue execution after an access violation. Unfortunately, the CLR’s exception handling model has always encouraged users to catch these serious errors by allowing programs to catch any exception at the top of the System.Exception hierarchy. But this is rarely the right thing to do. Writing catch (Exception e) is a common programming error because unhandled exceptions have serious consequences. But you might argue that if you don’t know what errors will be raised by a function, you should protect against all possible errors when your program calls that function. This seems like a reasonable course SEH exceptions are a different class from those exceptions raised by your program. A program might raise an exception because it tried to pop an item from an empty stack or tried to open a file that didn’t exist. All of these exceptions make sense in the context of your program’s execution. SEH exceptions refer to a context outside of your program. An access violation (AV), for example, indicates an attempted write to invalid memory. Unlike program errors, an SEH exception indicates that the integrity of the runtime’s process may have been compromised. But even though SEH exceptions are different from exceptions that derive from System.Exception, when the CLR delivers the SEH exception to a managed thread it can be caught with a catch (Exception e) statement. Some systems attempt to separate these two kinds of exceptions. The Microsoft Visual C++ compiler distinguishes between exceptions raised by a C++ throw statement and Win32 SEH exceptions if you compile your program with the /EH switch. This separation is useful because a normal program doesn’t know how to handle errors that it did not raise. If a C++ program tries to add an element to a std::vector, it should expect that the operation may fail due to msdnmagazine.com In the CLr 4.0, only designated exceptions indicate a corrupted process state. of action until you think about what it means to continue execution when your process is possibly in a corrupted state. Sometimes aborting and trying again is the best option: nobody likes to see a Watson dialog, but it’s better to restart your program than to have your data corrupted. Programs catching exceptions arising from contexts they don’t understand is a serious problem. But you can’t solve the problem by using exceptions specifications or some other contract mechanism. And it’s important that managed programs be able to receive notification of SEH exceptions because the CLR is a platform for many kinds of applications and hosts. Some hosts, such as SQL Server, need to have total control of their application’s process. Managed code that interoperates with native code sometimes must deal with native C++ exceptions or SEH exceptions. But most programmers who write catch (Exception e) don’t really want to catch access violations. They’d prefer that execution of their program stops when a catastrophic error occurs rather February 2009 17 http://msdn.microsoft.com/magazine/cc188737 http://www.microsoft.com/msj/0197/exception/exception.aspx http://www.microsoft.com/msj/0197/exception/exception.aspx 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.