The Exception Model

RE: The Exception Model

haacked — Wed, 01 Oct 2003 21:46:00 GMT

Are they hiring?

RE: The Exception Model

Anonymous — Thu, 02 Oct 2003 00:27:00 GMT

Dude you really need to write a book!

RE: The Exception Model

Mathew Nolton — Thu, 02 Oct 2003 04:05:00 GMT

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

RE: The Exception Model

Robert Hurlbut — Thu, 02 Oct 2003 04:28:00 GMT

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.

RE: The Exception Model

Anonymous — Thu, 02 Oct 2003 04:57:00 GMT

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.

RE: The Exception Model

Jeroen — Thu, 02 Oct 2003 10:39:00 GMT

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!

RE: The Exception Model

Jeroen Frijters — Thu, 02 Oct 2003 12:44:00 GMT

> 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 http://www.frijters.net/run.il (the Java source is at: http://www.frijters.net/run.txt)

RE: The Exception Model

John Cavnar-Johnson — Thu, 02 Oct 2003 17:46:00 GMT

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.

RE: The Exception Model

Frank Hileman — Thu, 02 Oct 2003 20:33:00 GMT

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: http://blogs.gotdotnet.com/brada/commentview.aspx/c9c61dbf-62a9-474f-a5fe-c171cdedb4f6

RE: The Exception Model

Sean McLeod — Thu, 02 Oct 2003 21:03:00 GMT

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?

RE: The Exception Model

Steve — Fri, 03 Oct 2003 09:38:00 GMT

Excellent article Chris - complete with a flashback or two from the past (I tried a 'Jonny Mnemonic' erasure on WinNT SEH) Thanks!

RE: The Exception Model

Steve — Fri, 03 Oct 2003 09:39:00 GMT

Excellent article Chris - complete with a flashback or two from the past (I tried a 'Jonny Mnemonic' erasure on WinNT SEH) Thanks!

RE: The Exception Model

Mike Dimmick — Fri, 03 Oct 2003 16:04:00 GMT

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).

RE: The Exception Model

Erick Sgarbi — Fri, 03 Oct 2003 17:44:00 GMT

" 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!

RE: The Exception Model

Sean McLeod — Sat, 04 Oct 2003 23:14:00 GMT

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? Cheers

RE: The Exception Model

Chris Brumme — Sun, 05 Oct 2003 00:12:00 GMT

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.

RE: The Exception Model

Chris Brumme — Sun, 05 Oct 2003 00:21:00 GMT

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!)

RE: The Exception Model

Rick Byers — Wed, 08 Oct 2003 20:49:00 GMT

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 (http://www.kinitos.com/). 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!

RE: The Exception Model

Zohar — Thu, 09 Oct 2003 02:07:00 GMT

>>(IErrorInfo anybody?) No thanks , I've just eaten...

RE: The Exception Model

Chris Brumme — Fri, 10 Oct 2003 16:56:00 GMT

Rick, 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.

RE: The Exception Model

Mark Morrell — Mon, 13 Oct 2003 19:42:00 GMT

Chris - I'm completely changing the subject on you. You started this article with: ----8<---- 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. ----8<---- 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.)

RE: The Exception Model

Mark Hurd — Tue, 14 Oct 2003 11:05:00 GMT

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.

RE: The Exception Model

Chris Brumme — Thu, 16 Oct 2003 22:15:00 GMT

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.

RE: The Exception Model

Rick Byers — Wed, 22 Oct 2003 19:07:00 GMT

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).

RE: The Exception Model

Chris Brumme — Thu, 23 Oct 2003 07:58:00 GMT

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.

RE: The Exception Model

Chris Dern — Tue, 28 Oct 2003 19:46:00 GMT

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

RE: The Exception Model

David Levine — Thu, 20 Nov 2003 23:08:00 GMT

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. Dave

RE: The Exception Model

Chris Brumme — Sat, 22 Nov 2003 19:40:00 GMT

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.

RE: The Exception Model

David Levine — Wed, 26 Nov 2003 14:07:00 GMT

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? Dave PS: Keep the long blogs.

re: The Exception Model

Wallym — Mon, 12 Jan 2004 17:22:00 GMT

You are the exception man in my book.

Wally

What do you think of .NET's exception model?

Watcher of the skies — Thu, 29 Jan 2004 01:40:00 GMT

VB.NET Propagating Improper SEH

Kirk Allen Evans' XML Blog — Thu, 29 Jan 2004 03:38:00 GMT

re: Why are RECTs endpoint-exclusive?

The Old New Thing — Thu, 19 Feb 2004 22:49:00 GMT

Exceptions and Assertions

Mark Treadwell — Wed, 24 Mar 2004 02:31:00 GMT

Exceptions and Assertions

Mark Treadwell — Wed, 24 Mar 2004 04:24:00 GMT

Custom Base Exception Class

Mark Treadwell — Sat, 27 Mar 2004 06:10:00 GMT

Custom Base Exception Class

Mark Treadwell — Fri, 02 Apr 2004 04:28:00 GMT

Exceptions and Assertions

Ohad's WebLog — Sat, 17 Jul 2004 16:56:00 GMT

re: The Exception Model

Nicu Georgian Fruja — Sun, 18 Jul 2004 19:35:00 GMT

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.

re: The Exception Model

Chris Brumme — Mon, 19 Jul 2004 17:31:00 GMT

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.

Adding a function to the safeseh list

greggm's WebLog — Thu, 22 Jul 2004 22:47:00 GMT

re: The Exception Model

Nicu Georgian Fruja — Tue, 27 Jul 2004 14:23:00 GMT

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.

re: The Exception Model

Chris Brumme — Tue, 27 Jul 2004 17:18:00 GMT

Nicu, I just re-read section 12.2.4.5 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.

re: Visas and degrees

Technical Careers @ Microsoft — Sat, 02 Oct 2004 06:33:00 GMT

re: How did MS-DOS report error codes?

The Old New Thing — Tue, 18 Jan 2005 12:53:00 GMT

Re: A Word from the

Alex Papadimoulis' WebLog — Wed, 30 Mar 2005 15:57:00 GMT

Custom Base Exception Class - V1 (VB)

.NET Hobbyist Programmer — Sun, 10 Jul 2005 06:21:10 GMT

Closing Documents Programmatically is not simple

Misha Shneerson — Mon, 25 Jul 2005 07:22:39 GMT

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

Closing Documents Programmatically is not simple

Misha Shneerson — Sun, 18 Sep 2005 09:54:06 GMT

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

Exceptions can take you into unnecessary code paths

Jeff Stong — Mon, 06 Feb 2006 20:48:48 GMT

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

Are you aware that you have thrown over 40,000 exceptions in the last 3 hours?

If broken it is, fix it you should — Thu, 23 Feb 2006 16:09:06 GMT

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

Win32 Exception 에 관하여

HeeJae's Blog — Thu, 09 Mar 2006 04:16:00 GMT

http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx
저도 아직 안 읽어 봤는데, 같이 일하는 팀 멤버가 읽어 보라고 해서...

Everything you never wanted to know about exceptions

Code obsessed — Wed, 05 Apr 2006 15:17:44 GMT

Under the hood: Win32 SEH

neoragex2002 — Sun, 16 Apr 2006 08:20:33 GMT

TrackBack From:http://neoragex2002.cnblogs.com/archive/0001/01/01/376402.html

Structured Error Handling... My oppinion on the subject.

AddressOf.com — Sat, 04 Nov 2006 06:48:47 GMT

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

Exception Handling

Mithun Shanbhag's Weblog — Tue, 23 Jan 2007 23:13:13 GMT

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

FxCop backlog themes: Exceptions

I may have joined the wrong side — Sat, 05 May 2007 19:49:18 GMT

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

Unknown exception - code e0434f4e (et e0434f4d)

CoqBlog — Sun, 22 Jul 2007 19:14:40 GMT

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

Are you aware that you have thrown over 40,000 exceptions in the last 3 hours?

If broken it is, fix it you should — Mon, 20 Aug 2007 15:25:46 GMT

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

Contact lenses articles » Row of bombs the exception of

Contact lenses articles » Row of bombs the exception of — Sun, 23 Dec 2007 11:54:27 GMT

PingBack from http://www.contactlensland.com/2007/12/23/row-of-bombs-the-exception-of/

Exceptions

Speaking of which... — Fri, 18 Jan 2008 18:50:39 GMT

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

Exceptions

Noticias externas — Fri, 18 Jan 2008 19:58:42 GMT

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

Still Learning » Blog Archive » Details on std::exception handling

Mon, 12 May 2008 08:18:08 GMT

PingBack from http://imehta.com/blog-ketan/?p=21

Getting good dumps when an exception is thrown

Rick Byers — Tue, 23 Dec 2008 10:45:04 GMT

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

try/catch in C# | keyongtech

try/catch in C# | keyongtech — Thu, 22 Jan 2009 08:17:15 GMT

PingBack from http://www.keyongtech.com/667901-try-catch-in-c

Three Reasons Not to use Exceptions for Model Validation

HACKINGON.NET — Fri, 13 Feb 2009 01:57:29 GMT

Three Reasons Not to use Exceptions for Model Validation

ThreadAbortException

CLR Team Blog — Tue, 28 Apr 2009 21:54:19 GMT

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

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Tue, 28 Apr 2009 23:20:08 GMT

PingBack from http://www.codedstyle.com/threadabortexception-10/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:36:49 GMT

PingBack from http://www.codedstyle.com/threadabortexception/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:37:23 GMT

PingBack from http://www.codedstyle.com/threadabortexception-2/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:37:44 GMT

PingBack from http://www.codedstyle.com/threadabortexception-3/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:38:06 GMT

PingBack from http://www.codedstyle.com/threadabortexception-4/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:38:31 GMT

PingBack from http://www.codedstyle.com/threadabortexception-5/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:38:46 GMT

PingBack from http://www.codedstyle.com/threadabortexception-6/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:39:12 GMT

PingBack from http://www.codedstyle.com/threadabortexception-7/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:39:31 GMT

PingBack from http://www.codedstyle.com/threadabortexception-8/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:40:30 GMT

PingBack from http://www.codedstyle.com/threadabortexception-11/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:40:59 GMT

PingBack from http://www.codedstyle.com/threadabortexception-12/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:41:50 GMT

PingBack from http://www.codedstyle.com/threadabortexception-14/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:42:57 GMT

PingBack from http://www.codedstyle.com/threadabortexception-17/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:43:22 GMT

PingBack from http://www.codedstyle.com/threadabortexception-18/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:43:50 GMT

PingBack from http://www.codedstyle.com/threadabortexception-19/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:44:13 GMT

PingBack from http://www.codedstyle.com/threadabortexception-20/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:45:22 GMT

PingBack from http://www.codedstyle.com/threadabortexception-22/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:46:15 GMT

PingBack from http://www.codedstyle.com/threadabortexception-24/

ThreadAbortException | Coded Style

ThreadAbortException | Coded Style — Thu, 07 May 2009 06:47:43 GMT

PingBack from http://www.codedstyle.com/threadabortexception-25/

cbrumme s WebLog The Exception Model | Paid Surveys

cbrumme s WebLog The Exception Model | Paid Surveys — Fri, 29 May 2009 19:20:25 GMT

PingBack from http://paidsurveyshub.info/story.php?title=cbrumme-s-weblog-the-exception-model

cbrumme s WebLog The Exception Model | Portable Greenhouse

cbrumme s WebLog The Exception Model | Portable Greenhouse — Mon, 01 Jun 2009 13:17:33 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=731

cbrumme s WebLog The Exception Model | Portable Greenhouse

cbrumme s WebLog The Exception Model | Portable Greenhouse — Mon, 01 Jun 2009 14:35:29 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=10354

cbrumme s WebLog The Exception Model | Menopause Relief

cbrumme s WebLog The Exception Model | Menopause Relief — Tue, 09 Jun 2009 03:15:02 GMT

PingBack from http://menopausereliefsite.info/story.php?id=1281

cbrumme s WebLog The Exception Model | Cellulite Creams

cbrumme s WebLog The Exception Model | Cellulite Creams — Tue, 09 Jun 2009 05:55:02 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=10585

cbrumme s WebLog The Exception Model | debt solutions

cbrumme s WebLog The Exception Model | debt solutions — Fri, 19 Jun 2009 20:18:59 GMT

PingBack from http://debtsolutionsnow.info/story.php?id=2139