The Exception Model

I had hoped this article would be on changes to the next version of the CLR which allow it to be hosted inside SQL Server and other “challenging” environments. This is more generally interesting than you might think, because it creates an opportunity for other processes (i.e. your processes) to host the CLR with a similar level of integration and control. This includes control over memory usage, synchronization, threading (including fibers), extended security models, assembly storage, and more.

However, that topic is necessarily related to our next release, and I cannot talk about deep details of that next release until those details have been publicly disclosed. In late October, Microsoft is holding its PDC and I expect us to disclose many details at that time. In fact, I’m signed up to be a member of a PDC panel on this topic. If you work on a database or an application server or a similarly complicated product that might benefit from hosting the CLR, you may want to attend.

After we’ve disclosed the hosting changes for our next release, you can expect a blog on hosting in late October or some time in November.

Instead, this blog is on the managed exception model. This is an unusual topic for me. In the past, I’ve picked topics where I can dump information without having to check any of my facts or do any research. But in the case of exceptions I keep finding questions I cannot answer. At the top level, the managed exception model is nice and simple. But – as with everything else in software – the closer you look, the more you discover.

So for the first time I decided to have some CLR experts read my blog entry before I post it. In addition to pointing out a bunch of my errors, all the reviewers were unanimous on one point: I should write shorter blogs.

Of course, we can’t talk about managed exceptions without first considering Windows Structured Exception Handling (SEH). And we also need to look at the C++ exception model. That’s because both managed exceptions and C++ exceptions are implemented on top of the underlying SEH mechanism, and because managed exceptions must interoperate with both SEH and C++


Windows SEH

Since it’s at the base of all exception handling on Windows, let’s look at SEH first. As far as I know, the definitive explanation of SEH is still Matt Pietrek’s excellent 1997 article for Microsoft Systems Journal: There have been some extensions since then, like vectored exception handlers, some security enhancements, and the new mechanisms to support IA64 and AMD64. (It’s hard to base exceptions on FS:[0] chains if your processor doesn’t have an FS segment register). We’ll look at all these changes shortly. But Matt’s 1997 article remains a goldmine of information. In fact, it was very useful to the developers who implemented exceptions in the CLR.

The SEH model is exposed by MSVC via two constructs:


  1. __try {…} __except(filter_expression) {…}
  2. __try {…} __finally {…}


Matt’s article explains how the underlying mechanism of two passes over a chain of single callbacks is used to provide try/except/finally semantics. Briefly, the OS dispatches an exception by retrieving the head of the SEH chain from TLS. Since the head of this chain is at the top of the TIB/TEB (Thread Information Block / Thread Environment Block, depending on the OS and the header file you look at), and since the FS segment register provides fast access to this TLS block on X86, the SEH chain is often called the FS:[0] chain.

Each entry consists of a next or a prev pointer (depending on how you look at it) and a callback function. You can add whatever data you like after that standard entry header. The callback function is called with all sorts of additional information related to the exception that’s being processed. This includes the exception record and the register state of the machine which was captured at the time of the exception.

To implement the 1st form of MSVC SEH above (__try/__except), the callback evaluates the filter expression during the first pass over the handler chain. As exposed by MSVC, the filter expression can result in one of three legal values:






Of course, the filter could also throw its own exception. That’s not generally desirable, and I’ll discuss that possibility and other flow control issues later.

But if you look at the underlying SEH mechanism, the handler actually returns an EXCEPTION_DISPOSITION:










So there’s some mapping that MSVC is performing here. Part of that mapping is just a trivial conversion between the MSVC filter values and the SEH handler values. For instance ExceptionContinueSearch has the value 1 at the SEH handler level but the equivalent EXCEPTION_CONTINUE_SEARCH has the value 0 at the MSVC filter level. Ouch.

But the other part of the mapping has to do with a difference in functionality. For example, ExceptionNestedException and ExceptionCollidedUnwind are primarily used by the OS dispatch mechanism itself. We’ll see the circumstances in which they arise later. More importantly, MSVC filters can indicate that the __except clause should run by returning EXCEPTION_EXECUTE_HANDLER. But we shall see that at the SEH level this decision is achieved by having the exception dispatch routine fix up the register context and then resuming execution at the right spot.

The EXCEPTION_CONTINUE_EXECUTION case supports a rather esoteric use of SEH. This return value allows the filter to correct the problem that caused the exception and to resume execution at the faulting instruction. For example, an application might be watching to see when segments are being written to so that it can log this information. This could be achieved by marking the segment as ReadOnly and waiting for an exception to occur on first write. Then the filter could use VirtualProtect to change the segment containing the faulting address to ReadWrite and then restart the faulting instruction. Alternatively, the application could have two VirtualAllocs for each region of memory. One of these could be marked as ReadOnly and the second could be a shadow that is marked as ReadWrite. Now the exception filter can simply change the register state of the CPU that faulted, so that the register containing the faulting address is changed from the ReadOnly segment to the shadowed ReadWrite segment.

Obviously anyone who is playing these games must have a lot of sophistication and a deep knowledge of how the program executes. Some of these games work better if you can constrain the code that’s generated by your program to only touch faulting memory using a predictable cliché like offsets from a particular register.

I’ll talk about this kind of restartable or resumable exception in the context of managed code later. For now, let’s pretend that the filter either returns “true – I would like my ‘except’ clause to handle this exception” or “false – my ‘except’ clause is uninterested in this exception”. If the filter returns false, the next SEH handler is fetched from the chain and it is asked this same question.

The OS is pretty paranoid about corrupt stacks during this chain traversal. It checks that all chain entries are within the bounds of the stack. (These bounds are also recorded in the TEB). The OS also checks that all entries are in ascending order on the stack. If you violate these rules, the OS will consider the stack to be corrupt and will be unable to process exceptions. This is one of the reasons that a Win32 application cannot break its stack into multiple disjoint segments as an innovative technique for dealing with stack overflow.

Anyway, eventually a handler says “true – I would like my ‘except’ clause to handle this exception”. That’s because there’s a backstop entry at the end of the chain which is placed there by the OS when the thread is created. This last entry wants to handle all the exceptions, even if your application-level handlers never do. That’s where you get the default OS behavior of consulting the unhandled exception filter list, throwing up dialog boxes for Terminate or Debug, etc.

As soon as a filter indicates that it wants to handle an exception, the first pass of exception handling finishes and the second pass begins. As Matt’s article explains, the handler can use the poorly documented RtlUnwind service to deliver second pass notifications to all the previous handlers and pop them off the handler chain.

In other words, no unwinding happened as the first pass progressed. But during the second pass we see two distinct forms of unwind. The first form involves popping SEH records from the chain that was threaded from TLS. Each such SEH record is popped before the corresponding handler gets called for the second pass. This leaves the SEH chain in a reasonable form for any nested exceptions that might occur within a handler.

The other form of unwind is the actual popping of the CPU stack. This doesn’t happen as eagerly as the popping of the SEH records. On X86, EBP is used as the frame pointer for methods containing SEH. ESP points to the top of the stack, as always. Until the stack is actually unwound, all the handlers are executed on top of the faulting exception frame. So the stack actually grows when a handler is called for the first or second pass. EBP is set to the frame of the method containing a filter or finally clause so that local variables of that method will be in scope.

The actual popping of the stack doesn’t occur until the catching ‘except’ clause is executed.

So we’ve got a handler whose filter announced in the first pass that it would handle this exception via EXCEPTION_EXECUTE_HANDLER. And that handler has driven the second pass by unwinding and delivering all the second pass notifications. Typically it will then fiddle with the register state in the exception context and resume execution at the top of the appropriate ‘except’ clause. This isn’t necessarily the case, and later we’ll see some situations where the exception propagation gets diverted.

How about the try/finally form of SEH? Well, it’s built on the same underlying notion of a chain of callbacks. During the first pass (the one where the filters execute, to decide which except block is going to catch), the finally handlers all say EXCEPTION_CONTINUE_SEARCH. They never actually catch anything. Then in the second pass, they execute their finally blocks.


Subsequent additions to SEH

All of the above – and a lot more – is in Matt’s article. There are a few things that aren’t in his article because they were added to the model later.

For example, Windows XP introduced the notion of a vectored exception handler. This allows the application to register for a first crack at an exception, without having to wait for exception handling to propagate down the stack to an embedded handler. Fortunately, Matt wrote an “Under The Hood” article on this particular topic. This can be found at

Another change to SEH is related to security. Buffer overruns – whether on the stack or in heap blocks – remain a favorite attack vector for hackers. A typical buffer overrun attack is to pass a large string as an argument to an API. If that API expected a shorter string, it might have a local on the stack like “char filename[256];”. Now if the API is foolish enough to strcpy a malicious hacker’s argument into that buffer, then the hacker can put some fairly arbitrary data onto the stack at addresses higher (further back on the stack) than that ‘filename’ buffer. If those higher locations are supposed to contain call return addresses, the hacker may be able to get the CPU to transfer execution into the buffer itself. Oops. The hacker is injecting arbitrary code and then executing it, potentially inside someone else’s process or under their security credentials.

There’s a new speed bump that an application can use to reduce the likelihood of a successful stack-based buffer overrun attack. This involves the /GS C++ compiler switch, which uses a cookie check in the function epilog to determine whether a buffer overrun has corrupted the return address before executing a return based on its value.

However, the return address trick is only one way to exploit buffer overruns. We’ve already seen that SEH records are necessarily built on the stack. And in fact the OS actually checks to be sure they are within the stack bounds. Those SEH records contain callback pointers which the OS will invoke if an exception occurs. So another way to exploit a buffer overrun is to rewrite the callback pointer in an SEH record on the stack. There’s a new linker switch (/SAFESEH) that can provide its own speed bump against this sort of attack. Modules built this way declare that all their handlers are embedded in a table in the image; they do not point to arbitrary code sequences sprinkled in the stack or in heap blocks. During exception processing, the exception callbacks can be validated against this table.

Of course, the first and best line of defense against all these attacks is to never overrun a buffer. If you are writing in managed code, this is usually pretty easy. You cannot create a buffer overrun in managed code unless the CLR contains a bug or you perform unsafe operations (e.g. unverifiable MC++ or ‘unsafe’ in C#) or you use high-privilege unsafe APIs like StructureToPtr or the various overloads of Copy in the System.Runtime.InteropServices.Marshal class.

So, not surprisingly and not just for this reason, I recommend writing in managed code. But if you must write some unmanaged code, you should seriously consider using a String abstraction that eliminates all those by-rote opportunities for error. And if you must code each strcpy individually, be sure to use strncpy instead!

A final interesting change to the OS SEH model since Matt’s article is due to Win64. Both IA64 and AMD64 have a model for exception handling that avoids reliance on an explicit handler chain that starts in TLS and is threaded through the stack. Instead, exception handling relies on the fact that on 64-bit systems we can perfectly unwind a stack. And this ability is itself due to the fact that these chips are severely constrained on the calling conventions they support.

If you look at X86, there are an unbounded number of calling conventions possible. Sure, there are a few common well-known conventions like stdcall, cdecl, thiscall and fastcall. But optimizing compilers can invent custom calling conventions based on inter-procedural analysis. And developers writing in assembly language can make novel decisions about which registers to preserve vs. scratch, how to use the floating point stack, how to encode structs into registers, whether to back-propagate results by re-using the stack that contained in-bound arguments, etc. Within the CLR, we have places where we even unbalance the stack by encoding data after a CALL instruction, which is then addressable via the return address. This is a particularly dangerous game because it upsets the branch prediction code of the CPU and can cause prediction misses on several subsequent RET instructions. So we are careful to reserve this technique for low frequency call paths. And we also have some stubs that compute indirect JMPs to out-of-line RET ‘n’ instructions in order to rebalance the stack.

It would be impossible for a stack crawler to successfully unwind these bizarre stacks for exception purposes, without completely simulating arbitrary code execution. So on X86 the exception mechanism must rely on the existence of a chain of crawlable FS:[0] handlers that is explicitly maintained.

Incidentally, the above distinction between perfect stack crawling on 64-bit systems vs. hopeless stack crawling on X86 systems has deeper repercussions for the CLR than just exception handling. The CLR needs the ability to crawl all the managed portions of a thread’s stack on all architectures. This is a requirement for proper enforcement of Code Access Security; for accurate reporting of managed references to the GC; for hijacking return addresses in order to asynchronously take control of threads; and for various other reasons. On X86, the CLR devotes considerable resources to achieving this.

Anyway, on 64-bit systems the correspondence between an activation record on the stack and the exception record that applies to it is not achieved through an FS:[0] chain. Instead, unwinding of the stack reveals the code addresses that correspond to a particular activation record. These instruction pointers of the method are looked up in a table to find out whether there are any__try/__except/__finally clauses that cover these code addresses. This table also indicates how to proceed with the unwind by describing the actions of the method epilog.


Managed Exceptions

Okay, enough about SEH – for now. Let’s switch to the managed exception model. This model contains a number of constructs. Depending on the language you code in, you probably only have access to a subset of these.


try {…} finally{…}


This is pretty standard. All managed languages should expose this, and it should be the most common style of exception handling in user code. Of course, in the case of MC++ the semantics of ‘finally’ is exposed through auto-destructed stack objects rather than through explicit finally clauses. You should be using ‘finally’ clauses to guarantee consistency of application state far more frequently than you use ‘catch’ clauses. That’s because catch clauses increase the likelihood that developers will swallow exceptions that should be handled elsewhere, or perhaps should even be left unhandled. And if catch clauses don’t actually swallow an exception (i.e. they ‘rethrow’), they still create a poor debugging experience as we shall see.


try {…} catch (Object o){…}


This is pretty standard, too. One thing that might surprise some developers is that you can catch any instance that’s of type Object or derived from Object. However, there is a CLS rule that only subtypes of System.Exception should be thrown. In fact, C# is so eager for you to only deal with System.Exception that it doesn’t provide any access to the thrown object unless you are catching Exception or one of its subtypes.

When you consider that only Exception and its subtypes have support for stack traces, HRESULT mapping, standard access to exception messages, and good support throughout the frameworks, then it’s pretty clear that you should restrict yourself to throwing and processing exceptions that derive from Exception.

In retrospect, perhaps we should have limited exception support to Exception rather than Object. Originally, we wanted the CLR to be a useful execution engine for more run-time libraries than just the .NET Frameworks. We imagined that different languages would execute on the CLR with their own particular run-time libraries. So we didn’t want to couple the base engine operations too tightly with CLS rules and constructs in the frameworks. Of course, now we understand that the commonality of the shared framework classes is a huge part of the value proposition of our managed environment. I suspect we would revisit our original design if we still could.


try {…} catch (Object o) if (expression) {…}


This is invented syntax, though I’m told it’s roughly what MC++ is considering. As far as I know, the only two .NET languages that currently support exception filters are VB.NET and – of course – ILASM. (We never build a managed construct without exposing it via ILDASM and ILASM in a manner that allows these two tools to round-trip between source and binary forms).

VB.NET has sometimes been dismissed as a language that’s exclusively for less sophisticated developers. But the way this language exposes the advanced feature of exception filters is a great example of why that position is too simplistic. Of course, it is true that VB has historically done a superb job of providing an approachable toolset and language, which has allowed less sophisticated developers to be highly productive.

Anyway, isn’t this cool:



…try statements…

Catch e As InvalidOperationException When expressionFilter

…catch statements…

End Try


Of course, at the runtime level we cannot separate the test for the exception type expression and the filter expression. We only support a bare expression. So the VB compiler turns the above catch into something like this, where $exception_obj is the implicit argument passed to the filter.


Catch When (IsInst($exception_obj, InvalidOperationException)

&& expressionFilter)


While we’re on the topic of exception handling in VB, have you ever wondered how VB .NET implements its On Error statement?


On Error { Goto { <line> | 0 | -1 } | Resume Next }


Me neither. But I think it’s pretty obvious how to implement this sort of thing with an interpreter. You wait for something to go wrong, and then you consult the active “On Error” setting. If it tells you to “Resume Next”, you simply scan forwards to the next statement and away you go.

But in an SEH world, it’s a little more complicated. I tried some simple test cases with the VB 7.1 compiler. The resulting codegen is based on advancing a _Vb_t_CurrentStatement local variable to indicate the progression of execution through the statements. A single try/filter/catch covers execution of these statements. It was interesting to see that the ‘On Error’ command only applies to exceptions that derive from System.Exception. The filter refuses to process any other exceptions.

So VB is nicely covered. But what if you did need to use exception filters from C#? Well, in V1 and V1.1, this would be quite difficult. But C# has announced a feature for their next release called anonymous methods. This is a compiler feature that involves no CLR changes. It allows blocks of code to be mentioned inline via a delegate. This relieves the developer from the tedium of defining explicit methods and state objects that can be gathered into the delegate and the explicit sharing of this state. This and other seductive upcoming C# features are described at

Using a mechanism like this, someone has pointed out that one could define delegates for try, filter and catch clauses and pass them to a shared chunk of ILASM. I love the way the C# compiler uses type inferencing to automatically deduce the delegate types. And it manufactures a state object to ensure that the locals and arguments of DoTryCatch are available to the “try statements”, “filter expression” and “catch statements”, almost as if everything was scoped in a single method body. (I say “almost” because any locals or arguments that are of byref, argiterator or typedbyref types cannot be disassociated from a stack without breaking safety. So these cases are disallowed).

I’m guessing that access to filters from C# could look something like this:


public void delegate__Try();

public Int32 delegate__Filter();

public void delegate__Catch();

// this reusable helper would be defined in ILASM or VB.NET:

void DoTryCatch(__Try t, __Filter f, __Catch c)

// And C# could then use it as follows:

void m(…arguments…)




{ …try statements…},

{ return filter_expression; },

{ …catch statements…}




You may notice that I cheated a little bit. I didn’t provide a way for the ‘catch’ clause to mention the exception type that it is catching. Of course, this could be expressed as part of the filter, but that’s not really playing fair. I suspect the solution is to make DoTryCatch a generic method that has an unbound Type parameter. Then DoTryCatch<T> could be instantiated for a particular type. However, I haven’t actually tried this so I hate to pretend that it would work. I am way behind on understanding what we can and cannot do with generics in our next release, how to express this in ILASM, and how it actually works under the covers. Any blog on that topic is years away.

While we are on the subject of interesting C# codegen, that same document on upcoming features also discusses iterators. These allow you to use the ‘yield’ statement to convert the normal pull model of defining iteration into a convenient push model. You can see the same ‘yield’ notion in Ruby. And I’m told that both languages have borrowed this from CLU, which pioneered the feature about the time that I was born.

When you get your hands on an updated C# compiler that supports this handy construct, be sure to ILDASM your program and see how it’s achieved. It’s a great example of what a compiler can do to make life easier for a developer, so long as we’re willing to burn a few more cycles compared to a more prosaic loop construct. In today’s world, this is almost always a sensible trade-off.

Okay, that last part has nothing to do with exceptions, does it? Let’s get back to the managed exception model.


try {…} fault {…}


Have you ever written code like this, to restrict execution of your finally clause to just the exceptional cases?


bool exceptional = true;

try {

…body of try…

exceptional = false;

} finally {

if (exceptional) {…}



Or how about a catch with a rethrow, as an alternate technique for achieving finally behavior for just the exceptional cases:


try {

} catch {




In each case, you are accommodating for the fact that your language doesn’t expose fault blocks. In fact, I think the only language that exposes these is ILASM. A fault block is simply a finally clause that only executes in the exceptional case. It never executes in the non-exceptional case.

Incidentally, the first alternative is preferable to the second. The second approach terminates the first pass of exception handling. This is a fundamentally different semantics, which has a substantial impact on debugging and other operations. Let’s look at rethrow in more detail, to see why this is the case.


Rethrow, restartable exceptions, debugging

Gee, my language has rethrow, but no filter. Why can’t I just treat the following constructs as equivalent?


try {…} filter (expression) catch (Exception e) {…}

try {…} catch (Exception e) { if (!expression) rethrow; …}


In fact, ‘rethrow’ tries hard to create the illusion that the initial exception handling is still in progress. It uses the same exception object. And it augments the stack trace associated with that exception object, so that it includes the portion of stack from the rethrow to the eventual catch.

Hmm, I guess I should have already mentioned that the stack trace of an Exception is intentionally restricted to the segment of stack from the throw to the catch. We do this for performance reasons, since part of the cost of an exception is linear with the depth of the stack that we capture. I’ll talk about the implications of exception performance later. Of course, you can use the System.Diagnostics.StackTrace class to gather the rest of the stack from the point of the catch, and then manually merge it into the stack trace from the Exception object. But this is a little clumsy and we have sometimes been asked to provide a helper to make this more convenient and less brittle to changes in the formatting of stack traces.

Incidentally, when you are playing around with stack traces (whether they are associated with exceptions, debugging, or explicit use of the StackTrace class), you will always find JIT inlining getting in your way. You can try to defeat the JIT inliner through use of indirected calls like function pointers, virtual methods, interface calls and delegates. Or you can make the called method “interesting” enough that the JIT decides it would be unproductive or too difficult to inline. All these techniques are flawed, and all of them will fail over time. The correct way to control inlining is to use the MethodImpl(MethodImplOptions.NoInlining) pseudo-custom attribute from the System.Runtime.CompilerServices namespace.

One way that a rethrow differs from a filter is with respect to resumable or restartable exceptions. We’ve already seen how SEH allows an exception filter to return EXCEPTION_CONTINUE_EXECUTION. This causes the faulting instruction to be restarted. Obviously it’s unproductive to do this unless the filter has first taken care of the faulting situation somehow. It could do this by changing the register state in the exception context so that a different value is dereferenced, or so that execution resumes at a different instruction. Or it could have modified the environment the program is running in, as with the VirtualProtect cases that I mentioned earlier.

In V1 and V1.1, the managed exception model does not support restartable exceptions. In fact, I think that we set EXCEPTION_NONCONTINUABLE on some (but perhaps not all) of our exceptions to indicate this. There are several reasons why we don’t support restartable exceptions:


  • In order to repair a faulting situation, the exception handler needs intimate knowledge about the execution environment. In managed code, we’ve gone to great lengths to hide these details. For example, there is no architecture-neutral mapping from the IL expression of stack-based execution to the register set of the underlying CPU.
  • Restartability is often desired for asynchronous exceptions. By ‘asynchronous’ I mean that the exception is not initiated by an explicit call to ‘throw’ in the code. Rather, it results from a memory fault or an injected failure like Abort that can happen on any instruction. Propagating a managed exception, where this involves execution of a managed filter, necessarily involves the potential for a GC. A JIT has some discretion over the GC-safe points that it chooses to support in a method. Certainly the JIT must gather GC information to report roots accurately at all call-sites. But the JIT normally isn’t required to maintain GC info for every instruction. If any instruction might fault, and if any such fault could be resumed, then the JIT would need GC info for all instructions in all methods. This would be expensive. Of course, ‘mov eax, ecx’ cannot fault due to memory access issues. But a surprising number of instructions are subject to fault if you consider all of memory – including the stack – to be unmapped. And even ‘mov eax, ecx’ can fault due to a Thread.Abort.


If you were paying attention to that last bullet, you might be wondering how asynchronous exceptions could avoid GC corruption even without resumption. After all, the managed filter will still execute and we know that the JIT doesn’t have complete GC information for the faulting instruction.

Our current solution to this on X86 is rather ad hoc, but it does work. First, we constrain the JIT to never flow the contents of the scratch registers between a ‘try’ clause and any of the exception clauses (‘filter’, ‘finally’, ‘fault’ and ‘catch’). The scratch registers in this case are EAX, ECX, EDX and sometimes EBP. Our JIT compiler decides, method-by-method, whether to use EBP as a stack-frame register or a scratch register. Of course, EBP isn’t really a scratch register since callees will preserve it for us, but you can see where I’m going.

Now when an asynchronous exception occurs, we can discard the state of all the scratch registers. In the case of EAX, ECX & EDX, we can unconditionally zero them in the register context that is flowed via exception propagation. In the case of EBP, we only zero it if we aren’t using EBP as a frame register. When we execute a managed handler, we can now report GC roots based on the GC information that’s associated with the handler’s instruction pointer.

The downside to this approach, other than its ad hoc nature, is that it constrains the codegen of any method that contains exception handlers. At some point we may have to model asynchronous exceptions more accurately, or expand the GC information spewed by the JIT compiler, or a combination, so that we can enable better code generation in the presence of exceptions.

We’ve already seen how VB.NET can use a filter and explicit logic flow from a catch clause to create the illusion of restartable exceptions to support ‘On Error Resume Next’. But this should not be confused with true restartability.

Before we leave the topic of rethrow, we should briefly consider the InnerException property of System.Exception. This allows one exception to be wrapped up in the state of another exception. A couple of important places where we take advantage of this are reflection and class construction.

When you perform late-bound invocation via reflection (e.g. Type.InvokeMember or MethodInfo.Invoke), exceptions can occur in two places:


  1. The reflection infrastructure may decide that it cannot satisfy your request, perhaps because you passed the wrong number of arguments, or the member lookup failed, or you are invoking on someone else’s private members. That last one sounds vaguely dirty.
  2. The late-bound invocation might work perfectly, but the target method you called may throw an exception back at you. Reflection must faithfully give you that exception as the result of the call. Returning it as an outbound argument, rather than throwing it at you, would be dangerous. We would lose one of the wonderful properties of exceptions, which is that they are hard to ignore. Error codes are constantly being swallowed or otherwise ignored, leading to fragile execution.


The problem is that these two sources of exceptions are ambiguous. There must be some way to tell whether the invocation attempt failed or whether the target of the invocation failed. Reflection disambiguates these cases by using an instance of System.Reflection.TargetInvocationException for the case where the invoked method threw an exception. The InnerException property of this instance is the exception that was thrown by the invoked method. If you get any exceptions from a late-bound invocation other than TargetInvocationException, those other exceptions indicate problems with the late-bound dispatch attempt itself.

Something similar happens with TypeInitializationException. If a class constructor (.cctor) method fails, we capture that exception as the InnerException of a TypeInitializationException. Subsequent attempts to use that class in this AppDomain from this or other threads will have that same TypeInitializationException instance thrown at them.

So what’s the difference between the following three constructs, where the overloaded constructor for MyExcep is placing its argument into InnerException:


try {…} catch (Exception e) { if (expr) rethrow; …}

try {…} catch (Exception e) { if (expr) throw new MyExcep(); …}

try {…} catch (Exception e) { if (expr) throw new MyExcep(e); …}


Well, the 2nd form is losing information. The original exception has been lost. It’s hard to recommend that approach.

Between the 1st and 3rd forms, I suppose it depends on whether the intermediary can add important information by wrapping the original exception in a MyExcep instance. Even if you are adding value with MyExcep, it’s still important to preserve the original exception information in the InnerException so that sophisticated programs and developers can determine the complete cause of the error.

Probably the biggest impact from terminating the first pass of exception handling early, as with the examples above, is on debugging. Have you ever attached a debugger to a process that has failed with an unhandled exception? When everything goes perfectly, the debugger pops up sitting in the context of the RaiseException or trap condition.

That’s so much better than attaching the debugger and ending up on a ‘rethrow’ statement. What you really care about is the state of the process when the initial exception was thrown. But the first pass has terminated and the original state of the world may have been lost. It’s clear why this happens, based on the two pass nature of exception handling.

Actually, the determination of whether or not the original state of the world has been lost or merely obscured is rather subtle. Certainly the current instruction pointer is sitting in the rethrow rather than on the original fault. But remember how filter and finally clauses are executed with an EBP that puts the containing method’s locals in scope… and an ESP that still contains the original faulting method? It turns out that the catching handler has some discretion on whether to pop ESP before executing the catch clause or instead to delay the pop until the catch clause is complete. The managed handler currently pops the stack before calling the catch clause, so the original state of the exception is truly lost. I believe the unmanaged C++ handler delays the pop until the catch completes, so recovering the state of the world for the original exception is tricky but possible.

Regardless, every time you catch and rethrow, you inflict this bitter disappointment on everyone who debugs through your code. Unfortunately, there are a number of places in managed code where this disappointment is unavoidable.

The most unfortunate place is at AppDomain boundaries. I’ve already explained at why the Isolation requirement of AppDomains forces us to marshal most exceptions across the boundary. And we’ve just discussed how reflection and class construction terminate the first pass by wrapping exceptions as the InnerException of an outer exception.

One alternative is to trap on all first-chance exceptions. That’s because debuggers can have first crack at exceptions before the vectored exception handler even sees the fault. This certainly gives you the ability to debug each exception in the context in which it was thrown. But you are likely to see a lot of exceptions in the debugger this way!

In fact, throughout V1 of the runtime, the ASP.NET team ran all their stress suites with a debugger attached and configured to trap on first-chance Access Violations (“sxe av”). Normally an AV in managed code is converted to a NullReferenceException and then handled like any other managed exception. But ASP.NET’s settings caused stress to trap in the debugger for any such AV. So their team enforced a rule that all their suites (including all dependencies throughout FX) must avoid such faults.

It’s an approach that worked for them, but it’s hard to see it working more broadly.

Instead, over time we need to add new hooks to our debuggers so they can trap on just the exceptions you care about. This might involve trapping exceptions that are escaping your code or are being propagated into your code (for some definition of ‘your code’). Or it might involve trapping exceptions that escape an AppDomain or that are propagated into an AppDomain.

The above text has described a pretty complete managed exception model. But there’s one feature that’s conspicuously absent. There’s no way for an API to document the legal set of exceptions that can escape from it. Some languages, like C++, support this feature. Other languages, like Java, mandate it. Of course, you could attach Custom Attributes to your methods to indicate the anticipated exceptions, but the CLR would not enforce this. It would be an opt-in discipline that would be of dubious value without global buy-in and guaranteed enforcement.

This is another of those religious language debates. I don’t want to rehash all the reasons for and against documenting thrown exceptions. I personally don’t believe the discipline is worth it, but I don’t expect to change the minds of any proponents. It doesn’t matter.

What does matter is that disciplines like this must be applied universally to have any value. So we either need to dictate that everyone follow the discipline or we must so weaken it that it is worthless even for proponents of it. And since one of our goals is high productivity, we aren’t going to inflict a discipline on people who don’t believe in it – particularly when that discipline is of debatable value. (It is debatable in the literal sense, since there are many people on both sides of the argument).

To me, this is rather like ‘const’ in C++. People often ask why we haven’t bought into this notion and applied it broadly throughout the managed programming model and frameworks. Once again, ‘const’ is a religious issue. Some developers are fierce proponents of it and others find that the modest benefit doesn’t justify the enormous burden. And, once again, it must be applied broadly to have value.

Now in C++ it’s possible to ‘const-ify’ the low level runtime library and services, and then allow client code to opt-in or not. And when the client code runs into places where it must lose ‘const’ in order to call some non-const-ified code, it can simply remove ‘const’ via a dirty cast. We have all done this trick, and it is one reason that I’m not particularly in favor of ‘const’ either.

But in a managed world, ‘const’ would only have value if it were enforced by the CLR. That means the verifier would prevent you from losing ‘const’ unless you explicitly broke type safety and were trusted by the security system to do so. Until more than 80% of developers are clamoring for an enforced ‘const’ model throughout the managed environment, you aren’t going to see us added it.


Foray into C++ Exceptions

C++ exposes its own exception model, which is distinct from the __try / __except /__finally exposure of SEH. This is done through auto-destruction of stack-allocated objects and through the ‘try’ and ‘catch’ keywords. Note that there are no double-underbars and there is no support for filters other than through matching of exception types. Of course, under the covers it’s still SEH. So there’s still an FS:[0] handler (on X86). But the C++ compiler optimizes this by only emitting a single SEH handler per method regardless of how many try/catch/finally clauses you use. The compiler emits a table to indicate to a common service in the C-runtime library where the various try, catch and finally clauses can be found in the method body.

Of course, one of the biggest differences between SEH and the C++ exception model is that C++ allows you to throw and catch objects of types defined in your application. SEH only lets you throw 32-bit exception codes. You can use _set_se_translator to map SEH codes into the appropriate C++ classes in your application.

A large part of the C++ exception model is implicit. Rather than use explicit try / finally / catch clauses, this language encourages use of auto-destructed local variables. Whether the method unwinds via a non-exceptional return statement or an exception being thrown, that local object will auto-destruct.

This is basically a ‘finally’ clause that’s been wrapped up in a more useful language construct. Auto-destruction occurs during the second pass of SEH, as you would expect.

Have you noticed that the C++ exception you throw is often a stack-allocated local? And that if you explicitly catch it, this catch is also with a stack-allocated object? Did you ever wake up at night in a cold sweat, wondering whether a C++ in-flight exception resides on a piece of stack that’s already been popped? Of course not.

In fact, we’ve now seen enough of SEH to understand how the exception always remains in a section of the stack above ESP (i.e. within the bounds of the stack). Prior to the throw, the exception is stack-allocated within the active frame. During the first pass of SEH, nothing gets popped. When the filters execute, they are pushed deeper on the stack than the throwing frame.

When a frame declares it will catch the exception, the second pass starts. Even here, the stack doesn’t unwind. Then, before resetting the stack pointer, the C++ handler can copy-construct the original exception from the piece of stack that will be popped into the activation frame that will be uncovered.

If you are an expert in unmanaged C++ exceptions, you will probably be interested to learn of the differences between managed C++ exceptions and unmanaged C++ exceptions. There’s a good write-up of these differences at


A Single Managed Handler

We’ve already seen how the C++ compiler can emit one SEH handler per method and reuse it for all the exception blocks in that method. The handler can do this by consulting a side table that indicates how the various clauses map to instruction sequences within that method.

In the managed environment, we can take this even further. We maintain a boundary between managed and unmanaged code for many reasons, like synchronization with the garbage collector, to enable stack crawling through managed code, and to marshal arguments properly. We have modified this boundary to erect a single SEH handler at every unmanaged -> managed call in. For the most part, we must do this without compiler support since many of our transitions occur through dynamically generated machine code.

The cost of modifying the SEH chain during calls into managed code is quickly amortized as we call freely between managed methods. So the immediate cost of pushing FS:[0] handlers on method entry is negligible for managed code. But there is still an impact on the quality of the generated code. We saw part of this impact in the discussion of register usage across exception clauses to remain GC-safe.

Of course, the biggest cost of exceptions is when you actually throw one. I’ll return to this near the end of the blog.


Flow Control

Here’s an interesting scenario that came up recently.

Let’s say we drive the first pass of exception propagation all the way to the end of the handler chain and we reach the unhandled exception backstop. That backstop will probably pop a dialog in the first pass, saying that the application has suffered an unhandled exception. Depending on how the system is configured, the dialog may allow us to terminate the process or debug it. Let’s say we choose Terminate.

Now the 2nd pass begins. During the 2nd pass, all our finally clauses can execute.

What if one of those 2nd pass ‘finally’ clauses throws a new exception? We’re going to start a new exception propagation from this location – with a new Exception instance. When we drive this new Exception up the chain, we may actually find a handler that will swallow the second exception.

If this is the case, the process won’t terminate due to that first exception. This is despite the fact that SEH told the user we had an unhandled exception, and the user told us to terminate the process.

This is surprising, to say the least. And this behavior is possible, regardless of whether managed or unmanaged exceptions are involved. The mechanism for SEH is well-defined and the exception model operates within those rules. An application should avoid certain (ab)uses of this mechanism, to avoid confusion.

Indeed, we have prohibited some of those questionable uses in managed code.

In unmanaged, you should never return from a finally. In an exceptional execution of a finally, a return has the effect of terminating the exception processing. The catch handler never sees its 2nd pass and the exception is effectively swallowed. Conversely, in a non-exceptional execution of a finally, a return has the effect of replacing the method’s return value with the return value from the finally. This is likely to cause developer confusion.

So in managed code we’ve made it impossible for you to return from a finally clause. The full rules for flow control involving managed exception clauses should be found at Section of ECMA Partition I (

However, it is possible to throw from a managed finally clause. (In general, it’s very hard to confidently identify regions of managed code where exceptions cannot be thrown). And this can have the effect of replacing the exception that was in flight with a new 1st and 2nd pass sweep, as described above. This is the ExceptionCollidedUnwind situation that is mentioned in the EXCEPTION_DISPOSITION enumeration.

The C++ language takes a different approach to exceptions thrown from the 2nd pass. We’ve already seen that C++ autodestructors execute during the 2nd pass of exception handling. If you’ve ever thrown an exception from the destructor, when that destructor is executed as part of an exception unwind, then you have already learned a painful lesson. The C++ behavior for this situation is to terminate the process via a termination handler.

In unmanaged C++, this means that developers must follow great discipline in the implementation of their destructors. Since eventually those destructors might run in the context of exception backout, those destructors should never allow an exception to escape them. That’s painful, but presumably achievable.

In managed C++, I’ve already mentioned that it’s very hard to identify regions where exceptions cannot occur. The ability to prevent (asynchronous and resource) exceptions over limited ranges of code is something we would like to enable at some point in the future, but it just isn’t practical in V1 and V1.1. It’s way too easy for an out-of-memory or type-load or class-initialization or thread-abort or appdomain-unload or similar exception to intrude.

Finally, it’s possible for exceptions to be thrown during execution of a filter. When this happens in an OS SEH context, it results in the ExceptionNestedException situation that is mentioned in the EXCEPTION_DISPOSITION enumeration. The managed exception model took a different approach here. We’ve already seen that an MSVC filter clause has three legal returns values (resume execution, continue search, and execute handler). If a managed filter throws an exception, we contain that exception and consider the filter to have replied “No, I don’t want to handle this one. Continue searching for a handler”.

This is a reasonable interpretation in all cases, but it falls out particularly well for stack overflow. With the historical OS support for stack overflow, it’s very hard to reliably execute backout code. As I’ve mentioned in other blogs, you may only have one 4K page of stack available for this purpose. If you blow that page, the process is terminated. It’s very hard to execute managed filters reliably within such a limited region. So a reasonable approach is to consider the filters to have themselves thrown a StackOverflowException and for us to interpret this as “No, I don’t want to handle this one.”

In a future version, we would like to provide a more defensible and useful mechanism for handling stack overflow from managed code.


Error Handling without Exceptions

So we’ve seen how SEH and C++ and managed exceptions all interoperate. But not all error handling is based on exceptions. When we consider Windows, there are two other error handling systems that the CLR can interoperate with. These are the Get/SetLastError mechanism used by the OS and the HRESULT / IErrorInfo mechanism used by COM.

Let’s look at the GetLastError mechanism first, because it’s relatively simple. A number of OS APIs indicate failure by returning a sentinel value. Usually this sentinel value is -1 or 0 or 1, but the details vary depending on the API. This sentinel value indicates that the client can call GetLastError() to recover a more detailed OS status code. Unfortunately, it’s sometimes hard to know which APIs participate in the GetLastError protocol. Theoretically this information is always documented in MSDN and is consistent from one version of the OS to the next – including between the NT and Win95-based OSes.

The real issue occurs when you PInvoke to one of these methods. The OS API latches any failure codes with SetLastError. Now on the return path of the PInvoke, we may be calling various OS services and managed services to marshal the outbound arguments. We may be synchronizing with a pending GC, which could involve a blocking operation like WaitForSingleObject. Somewhere in here, we may call another OS API that itself latches an error code (or the absence of an error code) through its own call to SetLastError.

So by the time we return to some managed code that can generate up a new PInvoke stub to call GetLastError, you can be sure that the original error code is long gone. The solution is to tag your PInvoke declaration to indicate that it should participate in the GetLastError protocol. This tells the PInvoke call to capture the error as part of the return path, before any other OS calls on this thread have an opportunity to erase it or replace it.

This protocol works well for PInvokes. Unfortunately, we do not have a way to tag IJW VTFixup stubs in the same way. So when you make managed -> unmanaged calls via MC++ IJW, there isn’t a convenient and reliable way to recover a detailed OS status code on the return path. Obviously this is something we would like to address in some future version, though without blindly inflicting the cost of a GetLastError on all managed -> unmanaged transitions through IJW.


COM Error Handling

To understand how the CLR interoperates with COM HRESULTs, we must first review how PreserveSig is used to modify the behavior of PInvoke and COM Interop.

Normally, COM signatures return an HRESULT error code. If the method needs to communicate some other result, this is typically expressed with an [out, retval] outbound argument. Of course, there are exceptions to this pattern. For example, IUnknown::AddRef and Release both return a count of the outstanding references, rather than an HRESULT. More importantly, HRESULTs can be used to communicate success codes as well as error codes. The two most typical success codes are S_OK and S_FALSE, though any HRESULT with the high bit reset is considered a success code.

COM Interop normally transforms the unmanaged signature to create a managed signature where the [out, retval] argument becomes the managed return value. If there is no [out, retval], then the return type of the managed method is ‘void’. Then the COM Interop layer maps between failure HRESULTs and managed exceptions. Here’s a simple example:


COM: HRESULT GetValue([out, retval] IUnknown **ppRet)

CLR: IUnknown GetValue()


However, the return value might be a DWORD-sized integer that should not be interpreted as an HRESULT. Or it might be an HRESULT – but one which must sometimes distinguish between different success codes. In these cases, PreserveSig can be specified on the signature and it will be preserved on the managed side as the traditional COM signature.

Of course, the same can happen with PInvoke signatures. Normally a DLL export like Ole32.dll’s CoGetMalloc would have its signature faithfully preserved. Presumably the transformation would be something like this:


DLL: HRESULT CoGetMalloc(DWORD c, [out, retval] IMalloc **ppRet)

CLR: DWORD CoGetMalloc(DWORD c, ref IMalloc ppRet)


If OLE32 returns some sort of failure HRESULT from this call, it will be returned to the managed caller. If instead the application would prefer to get this error case automatically converted to a managed Exception, it can use PreserveSig to indicate this.

Huh? In the COM case PreserveSig means “give me the unconverted HRESULT signature”, but in the PInvoke case PreserveSig means “convert my HRESULTs into exceptions.” Why would we use the same flag to indicate exactly opposite semantics for these two interop layers? The reasons are, ahem, historical. The best way to think of PreserveSig is “give me the unusual transformation of my signature, as opposed to what is typical for the kind of interop I am doing.”

So now we know how to obtain mappings between HRESULTs and managed exceptions for the typical COM Interop case (no PreserveSig) and the atypical PInvoke case (PreserveSig). But what are the details of that mapping?

The exception subsystem in the CLR has mappings between COM errors, OS errors, and managed exception types.

Of course, sometimes we have a situation which doesn’t have a precise mapping. In the case of an HRESULT that isn’t associated with a specific managed Exception class, we convert it to an instance of COMException. In the case of an OS status code that isn’t associated with a specific managed Exception class, we convert it to an instance of SEHException.

Even for cases where we have a correspondence between a managed and unmanaged representation, the mapping won’t necessarily roundtrip. For instance, an AV in unmanaged code results in an SEH exception of code 0xC0000005. If this is driven through managed code, it will be mapped to the corresponding NullReferenceException class. If the propagation of this exception continues through managed code and further up the stack to an unmanaged SEH handler, the unmanaged code will see the original exception code of
0xC0000005. So, when propagating through that sequence of handlers, we see a perfect roundtrip.

But let’s change the scenario slightly, so that the original AccessViolation occurs in managed code. Now we have a NullReferenceException that is being propagated out to an unmanaged SEH handler further back on the stack. But this time the NullReferenceException will be mapped to an SEH exception code of 0xE0434F4D. This is the managed exception code used for all managed exceptions.

Have you ever wondered where these exception codes come from? Well 0xE0434F4D is 0xE0+“COM”. Originally the CLR was called COM+ 2.0. When we changed the project name, we neglected to change the exception code. The unmanaged C++ exceptions use 0xE06D7363, which is 0xE0+“msc”. You might also see 0xE0524F54 for 0xE0+“ROT” on Rotor builds.

The current mapping between OS status codes and managed exception types is quite limited. It contains standard transformations like:





STATUS_FLOAT_UNDERFLOW => ArithmeticException






STATUS_ACCESS_VIOLATION => NullReferenceException


STATUS_NO_MEMORY => OutOfMemoryException

STATUS_STACK_OVERFLOW => StackOverflowException


The HRESULT mappings are far more extensive. They include standard mappings to the well-known HRESULT values like:


E_POINTER => ArgumentNullException


And they include mappings to CLR-defined HRESULTs in the 0x8013???? range that you’ve doubtless witnessed during your development and debugging. The managed platform has its own facility code for reserving a range of HRESULTs for our exclusive use.


COR_E_ENTRYPOINTNOTFOUND => EntryPointNotFoundException


And our mappings include a gathering of similar HRESULTs to a single managed exception. Here’s a particularly extensive gathering of 26 different HRESULTs to the FileLoadException class:





























There are some more observations we can make about the COM error handling approach. First, it should be obvious that the 32-bits of an HRESULT cannot uniquely define an arbitrary set of user-extensible error conditions. COM deals with this, in part, by including the interface that returns an HRESULT in the decision of how to interpret these 32-bits. This means that 0xE3021051 returned from IMyInterface is not the same error code as 0xE3201051 returned from IYourInterface. Unfortunately, it also means that each interface must be rigorous about the bit patterns it returns. Specifically, it would be very bad if the implementation of IMyInterface::m() happens to delegate to IYourInterface::n() and blindly return ‘n’s HRESULTs. Any HRESULTs returned from ‘n’ must somehow be mapped to the bit patterns that are legal to return from IMyInterface::m(). If ‘n’ returns a bit pattern that IMyInterface::m() cannot map, then ‘m’ is obligated to convert the HRESULT to E_UNEXPECTED and return that.

In other words, the uniqueness constraint for HRESULTs forces a painful discipline on all COM implementations that return HRESULTs. And part of this discipline is to lose error information by mapping meaningful HRESULTs into E_UNEXPECTED if the context for interpreting those HRESULTs is being lost. (There is a well-defined set of system HRESULTs which are implicitly returnable from any interface. The bit pattern for E_UNEXPECTED is necessarily part of this set. The CLR facility code allows us to live in this privileged world with our own codes).

The fact that most COM developers are unaware of this painful discipline and don’t follow it, just adds to the level of pain here.

Fortunately, COM supplements the limited expressibility and uniqueness of HRESULTs by using a second mechanism: IErrorInfo. And the COM Interop layer uses this supplementary mechanism when mapping to and from managed exception objects. In fact, System.Exception implements the IErrorInfo interface. When a managed exception is thrown to a COM client, the IErrorInfo of the Exception instance is available for the COM client to query.

Adam Nathan’s excellent book “.NET and COM – The Complete Interoperability Guide” describes how the IErrorInfo state is filled in from a managed exception in Chapter 16.

There’s one more detail of COM Interop HRESULT mapping that warrants discussion. It’s good practice for all COM methods to return an HRESULT. But there are several famous violations of this rule, including IUnknown::AddRef and Release. More importantly, every developer can choose whether to follow this best practice. Some choose not to. And there are some typical cases, like event sinks, where we often see methods returning ‘void’ or ‘bool’.

This presents the COM Interop error mapping layer with a problem. If an exception occurs inside a managed implementation of a method with one of these signatures, it’s hard to convey the error information back to the COM caller. There are several choices available to that layer – none of them good:


  1. Allow the managed exception to travel back through the COM caller, using the underlying SEH mechanism. This would work perfectly, but is strictly illegal. Well-behaved COM servers do not propagate exceptions out to their COM clients.
  2. Swallow the managed exception. Propagate a return value with ‘0’ out to the COM client. This 0 value might get interpreted as a returned Boolean, integer, pUnk or other data type. In the case of a ‘void’ signature, it will simply be ignored.
  3. Convert the exception object into an HRESULT value. Propagate that HRESULT out as the return value to the COM client. In the ‘void’ case, this will again be ignored. In the pUnk case, it will likely be dereferenced and subsequently cause an AccessViolation. (Failure HRESULTs have the high bit set. On Win32 the high 2 GB of address space are reserved for the kernel and are unavailable unless you run a /LARGEADDRESSAWARE process on a suitably booted system. On Win64, the low couple of GB of address are reserved and unavailable to detect this sort of mistake).


As you can see, all of these solutions are broken. Unfortunately, the most broken of the three is the last one… and that’s the one we currently follow. I suspect we will change our behavior here at some point. Until then, we rely on the fact that AddRef & Release are specially handled and that the other cases are rare and are typically ‘void’ or ‘bool’ returns.


Performance and Trends

Exceptions vs. error codes has always been a controversial topic. For the last 15 years, every team has argued whether their codebase should throw exceptions or return error codes. Hopefully nobody argues whether their team should mix both styles. That’s never desirable, though it often takes major surgery to migrate to a consistent plan.

With any religious controversy, there are many arguments on either side. Some of them are related to:


  • A philosophy of what errors mean and whether they should be expressed out-of-band with the method contract.
  • Performance. Exceptions have a direct cost when you actually throw and catch an exception. They may also have an indirect cost associated with pushing handlers on method entry. And they can often have an insidious cost by restricting codegen opportunities.
  • It’s relatively easy to forget to check for a returned error code. It’s much harder to inadvertently swallow an exception without handling it (though we still find developers doing so!)
  • Exceptions tend to capture far more information about the cause and location of an error, though one could envision an error code system that’s equally powerful. (IErrorInfo anybody?)


So what’s the right answer here?

Well if you are building the kernel of an operating system, you should probably use error codes. You are a programming God who rarely makes mistakes, so it’s less likely that you will forget to check your return codes. And there are sound bootstrapping and performance reasons for avoiding exceptions within the kernel. In fact, some of the OS folks here think that SEH should be reserved for terrible “take down the process” situations. That may have been the original design point. But SEH is such a flexible system, and it is so entrenched as the basis for unmanaged C++ exceptions and managed exceptions, that it is no longer reasonable to restrict the mechanism to these critical failures.

So, if you are not a programming God like those OS developers, you should consider using exceptions for your application errors. They are more powerful, more expressive, and less prone to abuse than error codes. They are one of the fundamental ways that we make managed programming more productive and less error prone. In fact, the CLR internally uses exceptions even in the unmanaged portions of the engine. However, there is a serious long term performance problem with exceptions and this must be factored into your decision.

Consider some of the things that happen when you throw an exception:


  • Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.
  • Run through a chain of handlers up the stack, calling each handler twice.
  • Compensate for mismatches between SEH, C++ and managed exceptions.
  • Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.
  • Probably take a trip through the OS kernel. Often take a hardware exception.
  • Notify any attached debuggers, profilers, vectored exception handlers and other interested parties.


This is light years away from returning a -1 from your function call. Exceptions are inherently non-local, and if there’s an obvious and enduring trend for today’s architectures, it’s that you must remain local for good performance.

Relative to straight-line local execution, exception performance will keep getting worse. Sure, we might dig into our current behavior and speed it up a little. But the trend will relentlessly make exceptions perform worse.

How do I reconcile the trend to worse performance with our recommendation that managed code should use exceptions to communicate errors? By ensuring that error cases are exceedingly rare. We used to say that exceptions should be used for exceptional cases, but folks pushed back on that as tautological.

If your API fails in 10% of all calls, you better not use an exception. Instead, change the API so that it communicates its success or failure as part of the API (e.g. ‘bool TryParse(String s)’). Even if the API fails 1% of calls, this may be too high a rate for a service that’s heavily used in a server. If 1% of calls fail and we’re processing 1000 requests per second with 100 of these API calls per request, then we are throwing 1000 times a second. That’s a very disturbing rate of exceptions. On the other hand, a 1% failure rate may be quite tolerable in a client scenario, if the exception occurs when a human user presses the wrong button.

Sometimes you won’t know whether your API will be used in a client or a server. And it may be hard for you to predict failure rates when errors are triggered by bad data from the client. If you’ve provided a way for the client to check his data without triggering an exception (like the TryParse() example above) then you’ve done your part.

As usual, there’s so much more to say. I still haven’t talked about unhandled exceptions. Or about undeniable exception propagation (Thread.Abort). Or how undeniable propagation interacts with propagation through unmanaged code via PInvoke, IJW or COM Interop. And I carefully avoided explaining why we didn’t follow our own rules when defining and using the Exception class hierarchy. And there’s plenty to say about our special treatment of OutOfMemoryException and StackOverflowException.

If you are still reading and actually want to know more, perhaps you should just apply for a job on the CLR team.

Comments (92)

  1. haacked says:

    Are they hiring?

  2. Anonymous says:

    Dude you really need to write a book!

  3. Chris, I enjoy blogging but I barely find the time to do it. How do you find the time to write small dissertations? 😉 Nice article as always. I plan on reading it in detail later.
    -Mathew Nolton

  4. Excellent article, as always! Thank you for discussing briefly how Thread.Abort interacts with the JIT. I, for one, am interested in the undeniable exception propagation (Thread.Abort) as I have fought the ThreadAbortException problem before. I have seen it documented in the Rotor (SSCLI) code, and tried to understand what was going on and why.

  5. Anonymous says:

    Aww, we have to get hired to learn more? Seems a bit over the top to have to move to the states just to learn about exceptions. 🙂

    Keep the articles long I say. Readers can always skim them if they don’t want to know the details, but if you do want to know the details and there’s only a short article, you’re out of luck. Better too long than too short.

  6. Jeroen says:

    I agree with the previous poster. I can find the general facts in the MSDN docs, blogs like these are great for getting the gritty details when you really want to know how something works. Thanks alot for writing stuff like this!

  7. I should write shorter blogs.

    Please don’t!

    Your going to love my exception handling in IKVM.NET (not!). I think I violate all of the best practices.

    Since Java compiles try { } finally {} as try {} catch() {} (and also allows returning from a finally block), I cannot use (at least it would be difficult) the CLR finally construct.

    I also create way too many exception handlers, because in Java it is legal to branch in to and out of exception handlers, so I have to split them. For a particularly nasty example, check out

    (the Java source is at:

  8. John Cavnar-Johnson says:

    Don’t waste any time trying to make your blogs shorter. The information density in your entries is the highest I’ve ever seen. There is no fluff to be cut. You are tackling complex issues at an incredibly detailed level and you have an excellent sense for what a single entry should be. You could conceivably divide this article at your section headings, but what’s the point? One of the benefits of blogging is that there are no artificial constraints on length (unlike a book or an MSDN article).

    I was an English major in college and an editor before becoming a software geek. Very few technical writers (even with good editors) can achieve the kind of clarity I see in your articles. Your target audience is small, but it is one that is very important to the success of .NET.

  9. Frank Hileman says:

    Please keep the long blogs. I don’t think any of your readers want shorter ones. Your internal reviewers were probably thinking of a different kind of audience.

    Your comments on the cost of exception throw/catch has reinforced my feeling that exceptions are are too frequently being recommended as an alternative to return values. I have seen how exception catching can bog down applications.

    I think that when designing a commonly used API, an exception should not be thrown when performing an operation, if there is no alternative way to determine that the exception will be thrown. That is, throwing an exception when passed a null reference is acceptable, because the caller can easily check for a null reference. But if an algorithm within a function throws an exception, and there is no way to pre-determine the exception will be thrown, without the API user duplicating the algorithm externally, an alternative, non-exception throwing function should be provided, or a return value should communicate failure instead. It is impossible for the API designer to predict the context in which the function will be used, and how often the exception may be thrown.

    Brad Adams started some discussions like this here:

  10. Sean McLeod says:

    On the topic of buffer overruns on the stack and getting code to execute from the stack, how come Intel haven’t added an option in their newer CPUs to allow the OS to mark the stack VM pages with Read/Write permission but ‘No Execute’ permission?

  11. Steve says:

    Excellent article Chris – complete with a flashback or two from the past (I tried a ‘Jonny Mnemonic’ erasure on WinNT SEH)


  12. Steve says:

    Excellent article Chris – complete with a flashback or two from the past (I tried a ‘Jonny Mnemonic’ erasure on WinNT SEH)


  13. Mike Dimmick says:

    Sean: about Intel (i.e. x86) CPUs.

    Firstly, I don’t think there’s room in the page table entry for an additional flag, you’d have to persuade the other manufacturers to do it too, and obviously this would only help on new processors (which the OS would have to detect correctly). IIRC, Windows already uses all three bits (11 to 9) of the page table entry for its own purposes – although I’d have to check Inside Windows 2000 to be sure.

    The x86 processor only executes code through the memory pointed to by the code segment register, but a segment can only be a contiguous region of virtual memory – it can’t consist of multiple non-contiguous regions. Existing programs expect not to have to manipulate the CS register; Windows currently sets all the segment registers apart from FS to point to segments with appropriate permissions set, but which address all 4GB of virtual memory (i.e. offset = 0, size = 0xFFFFFFFF). As Chris said, the FS register points to the Thread Information Block (actually, it points to an entry in the Segment Descriptor Table which describes a segment whose starting offset is the start address of the TIB). The FS register is the only segment register which gets used by typical Windows application code. Everything else is referenced by its default selector – all code is accessed through the CS selector, data through DS, stack through SS and string-destinations (for string-copy instructions such as MOVS) through ES. AMD64 ignores CS, DS, ES and SS in 64-bit mode; FS and GS still exist and are widened to reference a 64-bit base address, although the limit is now ignored.

    The new processor architectures, AMD64 and IA64, both permit execute/no execute permissions to be set on a per-page basis.

    Also, some libraries use areas of the stack for thunk code. I’m thinking particularly of ATL 6.0, which uses a dynamically-generated thunk as the actual window procedure passed to Windows. The thunk replaces the hWnd argument with the ‘this’ pointer of the referenced object, then calls the class’s static WindowProc function. Since the thunk is declared as a member of CWindowImplRoot, if you allocate a window object on the stack (perhaps for a modal dialog), you end up with the thunk on the stack requiring execute permissions.

    I note that in ATL 7.x for x86, the thunk will actually now be allocated in the process’s default heap rather than on the stack, although it’s still on the stack for other processors. See ATLWIN.H for CWndProcThunk and ATLBASE.H for CStdCallThunk (ATL 7.x only).

  14. Erick Sgarbi says:

    " I should write shorter blogs"
    Well, I believe Lincoln has said once, "I did not have time to write you a short message so I merely wrote a long one" which means that takes time to write something short and meaniful. I am sure you’re a very busy person yourself, which is taking your own private time to speak your mind and helping all of us (CLR wolves) to understand better this machinery.

    Put this way, if you take your time to write a very long article I will ensure to make myself time to read it full.

    Great work!

  15. Sean McLeod says:

    x86 no-execute VM pages.

    Yes it would only apply to newer cpus, but at 100 million plus new PCs per year the sooner it got in the more useful it would be.

    In terms of some code like ATL actually generating executable code on the stack etc. the option is to allow it to be an option per process so that a minimum ‘critical’ processes hosting things like rpcss etc. could run with this extra level of safety.

    Does anyone know whether the 64 bit versions of Windows use the execute permission bit to prevent the execution of code from certain pages under any circumstances?


  16. Chris Brumme says:

    I agree that taking advantage of "No Execute" pages on modern CPUs is essentially a no-brainer, in light of the current (and future) security environment. If I had to guess, it would be more a matter of when rather than if. Obviously a lot of software would have to change before we could support this broadly. For instance, the CLR itself is loaded into a lot of processes. And on X86 the CLR executes out of random heap blocks. I wouldn’t be surprised to find that we execute out of the stack in some cases, also. But we already needed to clean this up for 64-bit, so the incremental work for 32-bit may not be too bad.

  17. Chris Brumme says:

    It’s hard to know whether the question "Are they hiring?" was serious. Generally, Microsoft is always hiring. And I think the CLR team has had a couple of open head count pretty constantly for many years. The actual jobs change over time, between the different sub-teams (security, debugging, perf, etc.) and the different disciplines (dev, architect, mgmt, tester & pm). I suspect we’re a bit more rigorous & painful on our interviews than the typical Microsoft team. But if you are really serious about a job on the CLR, by all means email me directly. (If you can’t decode my email address from the NOSPAM version, you’ve already failed the first test!)

  18. Rick Byers says:

    Another excellent paper Chris! I agree you shouldn’t worry about making them any shorter. People are used to reading short blog entries, but I see your posts more like journal articles/papers. I print them out and read them during my commute, instead of reading them on-line like other blogs. You should definitely consider collecting your posts into book form at some point!

    But in a managed world, ‘const’ would only have value if it were enforced by the CLR.

    I disagree. Sure there would be incredible value in having the CLR enforce const-ness, but as you say the cost-benefit tradeoff is too high for the average case. However, I believe there would also be incredible value in having unverified const method parameters that are checked only at compile time.

    Generally, during development the caller of a method needs to know if the reference types being pased into the method will be modified in any way. For example, if they’re going to be modified, the caller may not be able to re-use it next time the current operation needs to be performed. More generally, knowing when objects are modified and when they’re not (or aren’t supposed to be) is necessary to keep track of the state of an algorithm.

    Today in .NET, this is specified in the API documentation. For example, the static method Array.Clear indicates the Array argument is modified, but Array.BinarySearch implies its argument is not. Of course the description of the method usually makes it clear, but that’s not always the case. It’s also common, even in high quality API references like the .NET MSDN docs, for the documentation to omit this detail.

    Since the programmer needs to know this information when manipulating the code, why not make the documentation explicit with machine-readable meta-data? If I declare some method ‘void Foo( const MyType m )’, I’m just saying that Foo doesn’t intend to modify the state of m. If I change my mind later and decide I am going to modify ‘m’, I’d like some automated way to determine (within my application) which of my callers are relying on the previous behaviour. With compile-time verified ‘const’, any such callers would now get a compiler error (or even just a warning). Of course, I’m not advocating semantic changes to an API once its in a production environment where versioning is an issue. But during development and refactoring, it’s incredibly important to be able to identify the call sites that will be affected by a semantic change. I’ve seen many developers ‘#if false’ out a method (or apply System.ObsoleteAttribute) just to accurately find all the static references to the method within the solution (VS.NET’s ‘Go to Reference’ is horribly inadequate here) – but that’s a much bigger problem.

    My point is just that many people find ‘const’ useful in C++, despite the fact it’s not enforced. The C++ standard says that the results of using const_cast<> are implementation-defined, but in my experience implementations intentionally allow the use of const_cast without any side effects, specifically because people use it as I’ve described. Many people that make religious use of ‘const’ in C++ find it to be a useful tool in API design and bug prevention.

    Here is a great example of the problem that has actually caused me real grief in the distributed-computing platform I work on ( I had code something like this (simplified for demonstration purposes):

    IClientChannelSinkProvider ccsp = new BinaryClientFormatterSinkProvider();
    ccsp.Next = new MyCustomProvider();
    if( <we need a Tcp channel> ) {
    channel = new TcpChannel( properties, ccsp, null );
    RegisterChannel( channel );

    if( <we need an Http channel> ) {
    channel = new HttpChannel( properties, ccsp, null );
    RegisterChannel( channel );

    This code works great if we’re creating EITHER a TcpChannel or an HttpChannel. However, if we need both channels, we’ll get a run-time exception creating the HttpChannel because the TcpChannel constructor modified my sink provider chain (appended a TcpClientTransportSinkProvider). The TcpChannel documentation doesn’t indicate the IClientChannelSinkProvider argument will be modified. I actually had to decompile System.Runtime.Remoting.dll (or look at the SSCLI – I forget which) to fully understand the problem here. Had C# supported const, I would have written the first 2 lines as:

    IClientChannelSinkProvider newCcsp = new BinaryClientFormatterSinkProvider();
    newCcsp.Next = new MyCustomProvider();
    const IClientChannelSinkProvider ccsp = newCcsp;

    And then, if the framework made use of ‘const’, I would have gotten a compiler error passing a ‘const IClientChannelSinkProvider’ to the TcpChannel constructor, and realized the problem right away.

    This functionality could even be added to the language in a backwards compatible way using attributes on the method parameters. The compiler could default to not checking const, but allow checking to be enabled. Perhaps only calls to classes/assemblies marked with [UsesConst] would be checked, or there would be both a [const] and [notconst] attribute. This would allow a project to benefit internally from the functionality, without requiring the entire .NET framework be updated with ‘const’ attributes.

    I’ve always justified the C# team’s decision to not support const by telling myself that it would probably provoke confusion because some developers would assume it was runtime-verified and end up introducing security problems. However, I don’t really believe this argument is sufficient. Some developers are surprised that fully trusted code can use reflection to access private members. In reality if you’re writing a trusted library whose clients may be untrusted and hostile you’re going to need a much stronger understanding of .NET security to get it right and are unlikely to make such a simple mistake.

    I would take this whole argument even further and say that compilers and languages could be doing a lot more to support compile-time and run-time contract verification, and that it would improve our ability to write robust and reliable software.

    Am I missing something here Chris? Is there some other reason I haven’t thought of that the C# team decided not to support compile-time verified const method parameters?

    Sorry for the long post. As I said, this is a religious issue <grin>. Keep up the awesome work!

  19. Zohar says:

    >(IErrorInfo anybody?)
    No thanks , I’ve just eaten…

  20. Chris Brumme says:


    There actually is an unenforced notion of ‘const’ available for compilers to share. Look at IsConstModifier in Microsoft.VisualC.dll. MC++ uses this as you would expect. For example, if you dump System.EnterpriseServices.Thunk.dll you will see it applied to static fields, pointers, and other parts of signatures. The CLR only uses these custom signature modifiers for binding / overload purposes.

    I actually think there’s a real risk with providing features like this without CLR enforcement. Or — in the case of ‘initonly’, which is ‘readonly’ in C# — providing features where the CLR enforces something different from what a developer might expect. During our V1 security push, we found many many examples where our framework developers had misinterpreted a C# compiler enforcement for a CLR enforcement and had erroneously built those assumptions into their security model. In some cases, we scrambled to add CLR enforcement at the end of V1. In other cases, we used FxCop and detailed source audits to remove those erroneous assumptions.

    For me, this was a real eye opener. The FX developers are very sophisticated. But it’s just too easy to confuse language model restrictions with execution model restrictions.

  21. Mark Morrell says:

    Chris –

    I’m completely changing the subject on you. You started this article with:


    I had hoped this article would be on changes to the next version of the CLR which allow it to be hosted inside SQL Server and other “challenging” environments. This is more generally interesting than you might think, because it creates an opportunity for other processes (i.e. your processes) to host the CLR with a similar level of integration and control.


    I’m about to embark on a significant development project, and right now am considering C#. Do you have any sort of criteria to decide what sorts of project should or should not run in the CLR? For instance, I would not expect MS Word, Excel, etc. to be written in C#. How do you decide?

    Also, do you know whether Microsoft is going to continue the older C++ environment? Assuming Microsoft continues to write non .NET software, will the older development platform continue to evolve and be supported?

    (And I’ll throw my vote in with the others. Keep ’em long. Cutting them shorter would only detract from their value.)

  22. Mark Hurd says:

    Mark Morrell: If I were starting Word or Excel from scratch VB.NET would be my language of choice. Sure some specific issues (performance, interop, etc) may arise that causes some other .NET language to be used for parts but VB is still the best at doing visual things in Windows.

  23. Chris Brumme says:

    I’m highly biased here. Long term, I would like to see managed code as the basis of Visual Studio, Office, device drivers and even the OS kernel. That’s a very long term. You shouldn’t be making your current product plans based on what we hope eventually to support. It’s hard for me to comment specifically on your application without some details. If you want to email me with those details, feel free.

    As for the language choice, I’m biased there too. I personally like C# because I have a long background with C and C++. I sometimes get frustrated that C# won’t let me do some of the obscure things the CLR supports. But I think they struck an excellent balance between a clean powerful language that has most of the dangerous edges removed. If I had a background with VB instead of C, I suspect I would be telling you something different.

  24. Rick Byers says:

    Thanks for the response Chris, I see your point and the insight into the FX team is valuable. I probably underestimate how easy it would be to fall into that trap (need that ‘pit of success’). Although I still think that if const violation was just a compiler warning (instead of an error), it would be harder for developers to think it was runtime enforced.

    Perhaps we need some kind of contract meta-information (eg. specified in the XML comments of a method) that could be verified outside the compiler (perhaps with a tool like FxCop). It just seems like a wasted opportunity to me to have significant aspects of a types contract specified only in non-machine readable form (i.e. in the documentation), where is can’t be verified automatically. This applies to much more than just const (my personal favourite topic is concurrency – its way too easy to have deadlock potential in a large concurrent C#/VB/C++/Java program).

  25. Chris Brumme says:

    I’m a huge believer in developer-authored statements about the semantics of their programs, particularly if there can be some level of automated checking of these statements. I agree with you that concurrency is a natural area to apply this sort of thing. Personally, I would like to see Eiffel-style pre-, post-conditions and invariants which can be selectively enabled. In the case of concurrency, locks could be ranked to avoid deadlocks. Recursion could be prevented with extra checks (on most locks).

    We’ve been looking at other places we could apply this sort of mechanism. I think it’s a ripe area for innovation both inside and outside Microsoft. But it’s important to avoid any confusion over whether these statements are runtime-enforced and therefore whether they can be a solid basis for building security.

  26. Chris Dern says:

    Are you comming ( here ) to the PDC? Ask the Experts?

  27. David Levine says:

    I don’t know if you still monitor these old sites once you generate a new blog but I’ll take a chance and hope you do and feel like answering one simple question.

    I was just wondering how the runtime handled simple try-finally semantics (no catch block). I know that the underlying OS traps an exception, propagates it to user level via the debugger ports (1st chance exception), to the app, etc. And then MSVC exposes try-finally and try-except semantics, and then the runtime maps those into the C# exception mechanism.

    I ask because I’ve seen a lot of references in documents, including here, about how expensive exception handling is in terms of performance and that the ratio of try-finally blocks to try-catch block should be on the order of 10:1.

    I would expect it would be easier (and far more consistent) to use the same mechanism for implementing try-finally semantics as is done for try-catch, but since this would involve round-tripping through the kernel (which would mean that all finallys are non-local) I thought that perhaps the runtime handled it differently, perhaps by directly running the chain of handlers via manipulating the FS:[0] register and stepping through the EXCEPTION_REGISTRATION records.

    If the runtime does use the OS to unwind the stack then where is the performance gain? It would still run the chain of frame-based handlers (twice – the second for finally semantics); the only gain I can think of is that the runtime would not need to generate a stack trace.

    Are there games played where if the execution stream reaches a known "good" point it knows it can execute the finally block and then JMPs directly to that code?

    What am I missing here? Thanks.


  28. Chris Brumme says:

    I think your question is about try/finally in a stack fragment that’s made up entirely of managed activation records. In that case, there’s only a single SEH handler which guards all the managed code. So we participate with the OS SEH mechanism in order to get first and second pass notifications to that single SEH handler. But then we do our own thing (on X86) while distributing the notification to the managed exception constructs within that range of managed code.

    Having said that, even in managed code on X86 where we can avoid the burden of SEH on every method, the cost of processing an exception remains high. I suspect that at some point we will do some work to make it faster. We have a number of ideas here. Some are incremental and some are fairly radical. But at the boundaries with unmanaged code, we are forced to participate in a very specific manner that is dictated by SEH.

    Regardless, the long term trend is for exception handling to become slower — in relative terms — than it is now. In other words, computers will get faster at doing local operations and relative to this they will become slower at doing non-local operations. Exception handling will always involve non-local processing.

  29. David Levine says:

    Thanks Chris, and you are correct that I was referring to managed stack fragments.

    If you ever get the desire to revisit this subject in a future blog I think an interesting topic would be on how the new 64 bit architectures will affect exception processing within the CLR. For example, you mentioned how it performs perfect stack unwinding without getting into the mechanisms. Would this be compatible with existing mechanims or would interop become more proplematic then it is now? And, getting back to the original question, how would this impact performance?

    PS: Keep the long blogs.

  30. Wallym says:

    You are the exception man in my book.


  31. Nicu Georgian Fruja says:

    Dear Chris, you did an excelent blog about the CLR Exception model! I found in your material so many useful details.

    I would still have two questions concerning the mechanism of the two passes. If I got your explanations right, you claimed that during the first pass, no frames are popped off from the stack. On the other hand, I’ve read in the ECMA 335 standard for CLR that, there are frames which are popped off also in the first pass: I suppose this happens when the calling position is not embedded within a protected block (try).

    Also, you stated that, in the first pass, all the handlers are executed on the faulting exception frame but still pointing to the corresponding frame. Does this mean, in particular, that every handler is actually executed on the operand stack of the method it belongs? I suppose it should be so: one reason could be the maxstack of each operand stack.

    Once again, many thanks for your great article.

  32. Chris Brumme says:

    I just glanced through the ECMA spec. I see where it states that the exception object is popped off the stack when various exception handlers complete execution. And it’s certainly the case that the frames for the filters themselves will be popped off the stack during first pass evaluation, as each filter completes execution. But no other frames should be popped during the first pass.

    You are correct that first pass handlers are pushed over the faulting frame, but they have the context of the method that defines the filter. In unmanaged SEH, this is often achieved by having ESP point to the top of the stack (where it belongs), but EBP points back to the stack frame that defined the filter. This use of EBP can bring all the locals of that containing method back into scope for the filter code to access.

  33. Thank you very much for the prompt answer.

    I found in ECMA (Partition II) the following: “Stack frames are discarded either as this second walk occurs or after the handler completes, depending on information in the exception handler array entry associated with the handling block.”

    You said something about the frames of the filters, but in ECMA, there is nothing about non-function frames (for the case of the filters) and consequently, I don’t see why the above sentence in ECMA will refer to them.

    When I’ve read the first time in ECMA, my understanding was the following: in the first pass, are discarded ONLY the stack frames of the methods with filters whose execution is complete, which are not embedded in protected blocks with finally/fault handlers and which do not want to handle the exception.

  34. Chris Brumme says:

    Nicu, I just re-read section of the ECMA spec. It’s hard to put algorithms into words, but I think that section does a decent job. To me, it seems clear that the frames are discarded during the second pass. The filters cannot be discarded as they are executed, because they are buried on the stack underneath finally blocks.

    I suppose an implementation that uses linked frames in the heap could selectively unlink and discard filter blocks. But that approach was never part of our design.

  35. Both Word and Excel OMs have APIs that allow closing documents programmatically. I suppose there are…

  36. Both Word and Excel OMs have APIs that allow closing documents programmatically. I suppose there are…

  37. Jeff Stong says:

    Tim, a fellow Compuware blogger, forwarded me a link to this Microsoft blog entry: Are you aware that…

  38. This may seem like a preposterous statement, but unfortunately it’s all too common.

    In my work I go…


    저도 아직 안 읽어 봤는데, 같이 일하는 팀 멤버가 읽어 보라고 해서…

  40. I’ve seen a couple of posts concerning the evils that VB.NET has concerning the following: Try Catch

  41. In-depth Articles- Matt Peitrek on the internals of SEH . Matt Pietrek on Vectored Exception Handling

  42. Since I started monitoring traffic on this blog a little more closely about a week ago, I had the unexpected

  43. CoqBlog says:

    Si vous utilisez un debugger comme windbg sur des applications managées, vous aurez peut être déjà vu

  44. This may seem like a preposterous statement, but unfortunately it’s all too common. In my work I go through

  45. Introduction This was originally intended to be a post on identifying and troubleshooting Exceptions

  46. Introduction This was originally intended to be a post on identifying and troubleshooting Exceptions

  47. Rick Byers says:

    Often, when an unexpected exception occurs in production code, applications want to generate (and potentially

  48. Three Reasons Not to use Exceptions for Model Validation

  49. System.Threading.ThreadAbortException is just plain weird. For instance, most exceptions happen because

Skip to main content