C＃はスタックオーバーフロー例外をキャッチします

スタックオーバーフロー例外をスローするメソッドを再帰的に呼び出しています。最初の呼び出しはtry catchブロックで囲まれていますが、例外はキャッチされていません。

スタックオーバーフロー例外は特別な方法で動作しますか？例外を適切にキャッチ/処理できますか？

関連するかどうかはわかりませんが、追加情報：

• メインスレッドで例外がスローされない

• コードが例外をスローしているオブジェクトは、Assembly.LoadFrom（...）。CreateInstance（...）によって手動でロードされます

2.0以降、StackOverflow例外は次の状況でのみキャッチできます。

1. CLRは、ホストされた環境で実行されています^*ホストでは、StackOverflow例外の処理を明確に許可しています
2. stackoverflow例外は、実際のスタックオーバーフロー状況が原因ではなく、ユーザーコードによってスローされます（参照）

_{^*「私のコードはCLRをホストし、CLRのオプションを構成します」のような「ホストされた環境」ではなく、「私のコードは共有ホスティングで実行されます」}

正しい方法はオーバーフローを修正することですが、...

より大きなスタックを自分に与えることができます：-

using System.Threading;
Thread T = new Thread(threadDelegate, stackSizeInBytes);
T.Start();

System.Diagnostics.StackTrace FrameCountプロパティを使用して、使用したフレームをカウントし、フレーム制限に達したときに独自の例外をスローできます。

または、残りのスタックのサイズを計算し、それがしきい値を下回ったときに独自の例外をスローすることができます：-

class Program
{
    static int n;
    static int topOfStack;
    const int stackSize = 1000000; // Default?

    // The func is 76 bytes, but we need space to unwind the exception.
    const int spaceRequired = 18*1024; 

    unsafe static void Main(string[] args)
    {
        int var;
        topOfStack = (int)&var;

        n=0;
        recurse();
    }

    unsafe static void recurse()
    {
        int remaining;
        remaining = stackSize - (topOfStack - (int)&remaining);
        if (remaining < spaceRequired)
            throw new Exception("Cheese");
        n++;
        recurse();
    }
}

チーズをとってください。;）

StackOverflowExceptionのMSDNページから：

以前のバージョンの.NET Frameworkでは、アプリケーションがStackOverflowExceptionオブジェクトをキャッチできました（たとえば、無制限の再帰から回復するため）。ただし、スタックオーバーフロー例外を確実にキャッチしてプログラムの実行を続行するには、かなりの追加コードが必要であるため、現在この方法は推奨されていません。

.NET Frameworkバージョン2.0以降、StackOverflowExceptionオブジェクトはtry-catchブロックでキャッチできず、対応するプロセスはデフォルトで終了します。したがって、スタックオーバーフローを検出して防止するためのコードを作成することをお勧めします。たとえば、アプリケーションが再帰に依存している場合は、カウンターまたは状態条件を使用して再帰ループを終了します。共通言語ランタイム（CLR）をホストするアプリケーションは、スタックオーバーフロー例外が発生したアプリケーションドメインをCLRがアンロードし、対応するプロセスを続行するように指定できることに注意してください。詳細については、ICLRPolicyManagerインターフェイスおよび共通言語ランタイムのホスティングを参照してください。

すでにいくつかのユーザーが言っているように、例外をキャッチすることはできません。ただし、それが発生している場所を見つけるのに苦労している場合は、ビジュアルスタジオがスローされたときに中断するように構成することをお勧めします。

そのためには、[デバッグ]メニューから[例外設定]を開く必要があります。以前のバージョンのVisual Studioでは、これは 'Debug'-'Exceptions'にあります。新しいバージョンでは、「デバッグ」-「Windows」-「例外設定」にあります。

設定を開いたら、「共通言語ランタイム例外」を展開し、「システム」を展開して、下にスクロールして「System.StackOverflowException」を確認します。次に、呼び出しスタックを確認し、呼び出しの繰り返しパターンを探します。これにより、スタックオーバーフローの原因となっているコードを修正するためにどこを探すべきかがわかります。

上記のように、プロセス状態が破損しているためにシステムによって発生したStackOverflowExceptionをキャッチすることはできません。ただし、例外をイベントとして認識する方法があります。

http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

.NET Frameworkバージョン4以降、このイベントは、イベントハンドラーがセキュリティ上重要でHandleProcessCorruptedStateExceptionsAttribute属性を持たない限り、スタックオーバーフローやアクセス違反など、プロセスの状態を破壊する例外に対しては発生しません。

それにもかかわらず、アプリケーションはイベント関数を終了した後に終了します（非常にダーティな回避策は、このイベント内でアプリを再起動することでした。しかし、ログには十分です！

.NET Frameworkバージョン1.0および1.1では、メインアプリケーションスレッド以外のスレッドで発生する未処理の例外はランタイムによってキャッチされるため、アプリケーションは終了しません。したがって、アプリケーションが終了せずにUnhandledExceptionイベントが発生する可能性があります。.NET Frameworkバージョン2.0以降、このようなサイレントエラーの累積的な影響には、パフォーマンスの低下、データの破損、ロックアップなどが含まれており、デバッグが困難だったため、子スレッドの未処理の例外に対するこのバックストップが削除されました。ランタイムが終了しない場合のリストを含む詳細については、マネージスレッドの例外を参照してください。

はい、CLR 2.0スタックオーバーフローは回復不可能な状況と見なされます。したがって、ランタイムはまだプロセスをシャットダウンします。

詳細については、ドキュメントhttp://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspxを参照してください

できません。CLRはあなたをさせません。スタックオーバーフローは致命的なエラーであり、回復できません。

ほとんどの投稿で説明できないので、別の領域を追加しましょう。

多くのウェブサイトでは、これを回避する方法は別のAppDomainを使用することであると言う人がいるので、これが発生するとドメインがアンロードされます。CLRのデフォルトの動作によってKillProcessイベントが発生し、デフォルトのAppDomainがダウンするため、これは完全に間違っています（CLRをホストしない限り）。

それは不可能であり、十分な理由があります（1つには、すべてのcatch（Exception）{}について考えてください）。

スタックオーバーフロー後も実行を継続する場合は、危険なコードを別のAppDomainで実行してください。CLRポリシーは、元のドメインに影響を与えることなく、オーバーフロー時に現在のAppDomainを終了するように設定できます。