StackOverflowException in .NET

There are three kind of so-called "asynchronous exceptions". That are the ThreadAbortException, the OutOfMemoryException and the mentioned StackOverflowException. Those excepions are allowed to occur at any instruction in your code.

And, there's also a way to overcome them:

The easiest is the ThreadAbortException. When the current code executes in a finally-block. ThreadAbortExceptions are kind of "moved" to the end of the finally-block. So everything in a finally-block can't be aborted by a ThreadAbortException.

To avoid an OutOfMemoryException, you have only one possibility: Do not allocate anything on the Heap. This means that you're not allowed to create any new reference-types.

To overcome the StackOverflowException, you need some help from the Framework. This help manifests in Constrained Execution Regions. The required stack is allocated before the actual code is executed and additionally also ensures that the code is already JIT-Compiled and therefor is available for execution.

There are three forms to execute code in Constrained Execution Regions (copied from the BCL Team Blog):

• ExecuteCodeWithGuaranteedCleanup, a stack-overflow safe form of a try/finally.
• A try/finally block preceded immediately by a call to RuntimeHelpers.PrepareConstrainedRegions. The try block is not constrained, but all catch, finally, and fault blocks for that try are.
• As a critical finalizer - any subclass of CriticalFinalizerObject has a finalizer that is eagerly prepared before an instance of the object is allocated.
  • A special case is SafeHandle's ReleaseHandle method, a virtual method that is eagerly prepared before the subclass is allocated, and called from SafeHandle's critical finalizer.

You can find more at these blog posts:

Constrained Execution Regions and other errata [Brian Grunkemeyer] at the BCL Team Blog.

Joe Duffy's Weblog about Atomicity and asynchronous exception failures where he gives a very good overview over asynchronous exceptions and robustness in the .net Framework.

Not really; a stack overflow, or an out of memory exception happens within the CLR itself means something has gone critically wrong (I usually get it when I've been a dumbass and created a recursive property).

When this state occurs there is no way for the CLR to allocate new function calls or memory to enable it to call into the exception handlers; it's a "we must halt now" scenario.

If, however, you throw the exception yourself your exception handlers will be called.

A stackoverflow isn't something you can just recover from, since it can't allocate more stack memory to even call your exception handler.

The only thing you can really do is track down the cause and prevent it from happening at all (eg becareful with recursion, and don't allocate large objects on the stack).

blowdart nailed it, above. Dumbass recursive property, as he likes to call it. Really just a problem with typing code too quickly.

private Thing _myThing = null;

Public Thing MyThing
{
   get{
        return this.MyThing;}
   set{
        this.MyThing = value;}
}