例外処理（プログラミング）

コンピュータ プログラミングでは、例外処理のための言語メカニズムがいくつか存在します。例外という用語は通常、例外的な状況に関する情報を格納するデータ構造を示すために使用されます。制御を転送する、つまり例外を発生させるメカニズムの 1 つは、 throwと呼ばれています。例外はthrow されると言われます。実行はcatchに転送されます。

プログラミング言語は、例外の概念がかなり異なります。例外は、異常で予測不可能なエラーのある状況を表現して処理するために使用できますが、通常の状況を処理するためのフロー制御構造としても使用できます。たとえば、Python のイテレータは、イテレータによって生成される項目がこれ以上ないことを示すために StopIteration 例外をスローします。^[1]多くの言語では、例外の慣用的な使用法を構成するものについて意見の相違があります。たとえば、Joshua Bloch は、Java の例外は例外的な状況にのみ使用すべきであると述べていますが、^[2] Kiniry は、Java の組み込みはFileNotFoundException例外的なイベントではないと指摘しています。^[3]同様に、C++ の作者である Bjarne Stroustrup は、C++ 例外はエラー処理にのみ使用すべきであると述べています。これは、例外がエラー処理用に設計されたためです。^[4] Kiniry は、Ada、C++、Modula-3、ML および OCaml、Python、Ruby などの多くの最新言語がフロー制御に例外を使用していると指摘しています。 Eiffel、C#、Common Lisp、Modula-2などの言語では例外の使用を制限するために協調的な努力が行われていますが、これは技術的なレベルではなく社会的レベルで行われています。^[3]

ソフトウェア例外処理は 1960 年代から 1970 年代にかけて開発されました。LISP 1.5 (1958-1961) ^{[5] では、}ERRORインタープリタやコンパイラによって発生するエラーと同様に、擬似関数によって例外を発生させることができました。例外はERRORSETキーワードによってキャッチされ、キーワードはNILプログラムを終了したりデバッガに入ったりするのではなく、エラーが発生した場合に返されました。^[6] PL/I は1964 年頃に独自の例外処理形式を導入し、割り込みを ON ユニットで処理できるようにしました。^[7] MacLisp はERRSET、と がERRエラー発生だけでなく非ローカル制御フローにも使用されていることに着目し、CATCHとという 2 つの新しいキーワードを追加しましたTHROW(1972 年 6 月)。^[8]現在一般に「finally」と呼ばれるクリーンアップ動作は、1970 年代半ばから後半にかけてNILUNWIND-PROTECT (New Implementation of LISP) で として導入されました。^{[9]これはその後}Common Lispに採用されました。これと同時期にdynamic-windScheme で導入され、例外はクロージャで処理されました。構造化例外処理に関する最初の論文はGoodenough（1975a）とGoodenough（1975b）でした。^[10]その後、例外処理は1980年代以降、多くのプログラミング言語で広く採用されました。

多くのコンピュータ言語には、例外および例外処理の構文サポートが組み込まれています。これには、ActionScript、Ada、BlitzMax、C++、C#、Clojure、COBOL、D、ECMAScript、Eiffel、Java、ML、Object Pascal（Delphi、Free Pascalなど）、PowerBuilder、Objective-C、OCaml、Perl、^[11] PHP（バージョン5以降）、PL/I、PL/SQL、Prolog、Python、REALbasic、Ruby、Scala、Seed7、Smalltalk、Tcl、Visual Prolog、およびほとんどの.NET言語が含まれます。

細かい構文の違いを除けば、使用されている例外処理スタイルは 2、3 しかありません。最も一般的なスタイルでは、例外は、例外オブジェクト (Java や Object Pascal など) または特殊な拡張可能な列挙型 (Ada や SML など) の値を持つ特殊な文 (throwまたはraise) によって開始されます。例外ハンドラのスコープは、マーカー句 (tryまたは言語のブロック開始子など) で始まり、最初のハンドラ句 ( 、、 )beginの開始で終わります。ハンドラ句は複数続けることができ、それぞれが処理する例外タイプと例外オブジェクトに使用する名前を指定できます。小さなバリエーションとして、一部の言語では、例外のクラスを内部的に処理する単一のハンドラ句を使用します。 catchexceptrescue

また、例外が発生したかどうかに関わらず実行される関連節 (finallyまたは) も一般的であり、通常は例外処理ブロックの本体内で取得されたリソースを解放するために実行されます。注目すべきことに、C++ はこの構造を提供しておらず、代わりにデストラクタ を使用してリソースを解放するリソース取得初期化(RAII) 手法を推奨しています。^{[12] Westley Weimer と}George Neculaによる 2008 年の論文によると、Java の...ブロックの構文はソフトウェアの欠陥の一因となっています。メソッドが 3～5 個のリソースの取得と解放を処理する必要がある場合、プログラマーは可読性を考慮して、ブロックを十分にネストすることを望まないようです。これは、正しい解決策である場合でも同様です。複数のリソースを処理する場合でも、単一の...ブロックを使用することは可能ですが、それにはセンチネル値を正しく使用する必要があり、これがこの種の問題でよくあるバグのもう 1 つの原因です。^{[13] : 8:6–8:7}ensuretryfinallytryfinally

elsePython と Ruby では、ハンドラーのスコープの終わりに達する前に例外が発生しなかった場合に使用される 句 ( ) も許可されます。

全体として、例外処理コードは次のようになります ( Javaのような疑似コード)。

試してください{ line = console.readLine ( ) ; 
      

    if ( line . length () == 0 ) { throw new EmptyLineException ( "コンソールから読み取られた行は空でした!" ); }    
          
    

    console.printLine ( "こんにちは%s!" % line ); } catch ( EmptyLineException e ) { console.printLine ( "こんにちは!" ) ; } catch ( Exception e ) { console.printLine ( "エラー: " + e.message ( ) ); } else { console.printLine ( "プログラムは正常に実行されました。" ) ; } finally { console.printLine ( "プログラムを終了しています。" ); }  

   
    

   
      

 
    

 
    

C言語にはtry-catch例外処理はありませんが、エラーチェックには 戻りコードを使用します。標準ライブラリ関数setjmpとlongjmpマクロを使用してtry-catch処理を実装できます。^[14]

Perl 5ではdieforthrowとfor try-catchが使用されています。try-catchセマンティクスを提供するCPANモジュールがあります。^[15]eval {} if ($@) {}

例外がスローされると、プログラムは例外ハンドラが見つかるまで関数呼び出しのスタックをさかのぼって検索します。一部の言語では、この検索が進むにつれてスタックをアンワインドする必要があります。つまり、例外Eのハンドラ Hを含む関数fが関数gを呼び出し、関数gが関数hを呼び出し、 hで例外E が発生した場合、関数hとg は終了し、fのH はE を処理します。これは終了セマンティクスと呼ばれます。または、例外処理メカニズムは例外ハンドラへのエントリ^{[注 1]}でスタックをアンワインドせず、例外ハンドラに計算を再開、再開、またはアンワインドするオプションを与える場合があります。これにより、プログラムはエラーが発生した場所とまったく同じ場所から計算を続行したり (たとえば、以前は不足していたファイルが使用可能になった場合)、例外処理メカニズムの上に通知、ログ、クエリ、および流動的な変数を実装したりできます (Smalltalk で行われているように)。計算を中断したところから再開できるようにすることを再開セマンティクスと呼びます。

どちらの決定にも、理論的および設計上の議論があります。1989年から1991年にかけてのC++標準化の議論の結果、C++では終了セマンティクスを使用するという決定が下されました。^[16] Bjarne Stroustrupは、Jim Mitchellのプレゼンテーションを重要なデータポイントとして引用しています。

ジムは20年間にわたり6つの言語で例外処理を使用しており、ゼロックスのCedar/Mesaシステムの主要な設計者および実装者の1人として再開セマンティクスの初期の提唱者でした。彼のメッセージは

「再開よりも解雇の方が好ましい。これは意見の問題ではなく、長年の経験の問題だ。再開は魅力的だが、有効ではない。」

彼はこの主張を、いくつかのオペレーティングシステムの経験で裏付けました。重要な例は Cedar/Mesa です。これは再開を好み、使用する人々によって書かれましたが、10 年間使用された後、50 万行のシステムで再開が使われていたのはコンテキストの照会だけでした。再開は実際にはそのようなコンテキストの照会には必要なかったので、再開を削除したところ、システムのその部分で大幅な速度向上が見られました。再開が使用されていたすべてのケースで、10 年間にわたって問題となり、より適切な設計に置き換えられました。基本的に、再開の使用はすべて、個別の抽象化レベルを分離して維持できなかったことを表していました。^[10]

再開機能を備えた例外処理言語には、条件システムを備えたCommon Lisp 、PL/I、Dylan、 R、^[17]、Smalltalkなどがあります。ただし、新しいプログラミング言語の大部分はC++に準拠し、終了セマンティクスを使用しています。

プログラミング言語における例外処理の実装には、通常、コードジェネレータとコンパイラに付随するランタイムシステムの両方からのかなりのサポートが必要です。（C++に例外処理が追加されたことで、オリジナルのC++コンパイラであるCfrontの耐用年数が終わりました。^[18]）最も一般的なスキームは2つあります。1つ目は、動的登録は、例外処理の観点からプログラムの状態に関する構造を継続的に更新するコードを生成します。^[19] 通常、これは、そのフレームに関連付けられた関数またはメソッドで使用できるハンドラーを認識する新しい要素をスタックフレームレイアウトします。例外がスローされると、レイアウト内のポインターがランタイムを適切なハンドラーコードに誘導します。このアプローチはスペースの点ではコンパクトですが、フレームの開始と終了時に実行オーバーヘッドが追加されます。これは、たとえば、他の多くの言語機能で複雑な生成とランタイムサポートがすでに必要とされていた多くのAda実装で一般的に使用されていました。Microsoftの32ビット構造化例外処理（SEH）は、別の例外スタックでこのアプローチを使用します。^[20]動的登録は定義がかなり簡単なので、正当性の証明。^[21]

2番目の方式は、多くの製品品質のC++コンパイラと64ビットMicrosoft SEHに実装されており、テーブル駆動型アプローチ。これはコンパイル時およびリンク時例外処理に関するプログラム カウンターの範囲とプログラムの状態を関連付ける^[22] 次に、例外がスローされると、ランタイム システムはテーブル内の現在の命令の位置を調べ、実行中のハンドラーと実行する必要がある処理を決定します。このアプローチは、例外がスローされない場合の実行オーバーヘッドを最小限に抑えます。これにはいくらかのスペースが消費されますが、このスペースは、例外が実際にスローされるまでロードまたは再配置されない、読み取り専用の特殊目的データ セクションに割り当てることができます。^[23] 例外を処理するためのコードの位置 (メモリ内) は、関数の残りのコードが格納されているメモリ領域内 (またはその近く) に配置する必要はありません。したがって、例外がスローされた場合、必要な例外処理コードをロード/キャッシュする必要がある場合、パフォーマンスの低下 (関数呼び出し^[24]) が発生する可能性があります。ただし、例外がスローされない場合は、このスキームのパフォーマンス コストは最小限です。例外的な(つまり、まれな) イベントであるはずなのでC++ における例外処理を説明する際に^{[注 2]}実行時型識別(RTTI) と同様に、例外は C++ のゼロオーバーヘッド原則に従わない可能性があります。これは、実行時に例外処理を実装するには、ルックアップ テーブル用にゼロ以外の量のメモリが必要になるためです。^[25][25]組み込みシステムなどでは役立つ場合がありますスレッド セーフティを実現するという点でも優れています^[要出典]。

他の定義および実装スキームも提案されている。メタプログラミングをサポートする言語では、オーバーヘッドを全く伴わないアプローチ（既存のリフレクションのサポート以外）が提案されている。^[26]

例外に関する別の見方は、契約による設計の原則に基づいており、特にEiffel 言語によってサポートされています。その考え方は、「正常」な動作と「異常」な動作を正確に定義することで、例外処理のより厳密な基盤を提供することです。具体的には、このアプローチは次の 2 つの概念に基づいています。

• 失敗: 操作がその契約を履行できないこと。たとえば、加算によって算術オーバーフローが発生する場合 (数学的な合計の近似値を計算するという契約を履行しない)、またはルーチンが事後条件を満たせない場合があります。
• 例外: ルーチンの実行中に発生する異常なイベント (そのルーチンは例外の「受信者」です)。このような異常なイベントは、ルーチンによって呼び出された操作の失敗によって発生します。

Bertrand Meyer が『オブジェクト指向ソフトウェア構築』で紹介した「安全な例外処理の原則」では、例外が発生したときにルーチンが対応できる意味のある方法は 2 つしかないとされています。

• 失敗、または「組織化されたパニック」: ルーチンは不変条件を再確立してオブジェクトの状態を修正し (これが「組織化された」部分です)、その後失敗 (パニック) し、呼び出し元で例外をトリガーします (異常なイベントが無視されないようにするため)。
• 再試行: ルーチンは通常、次の試行が成功する可能性が高くなるようにいくつかの値を変更した後、アルゴリズムを再試行します。

特に、例外を単に無視することは許可されていません。ブロックを再試行して正常に完了するか、例外を呼び出し元に伝播する必要があります。

これは、Eiffel 構文で表現された例です。ルーチンはsend_fast通常、メッセージを送信するより良い方法であると想定していますが、失敗して例外がトリガーされる可能性がありますsend_slow。その場合、アルゴリズムは次に を使用します。これは、失敗する頻度が低くなります。 がsend_slow失敗すると、ルーチンsend全体が失敗し、呼び出し元で例外が発生します。

send ( m : MESSAGE )は、可能であれば m を高速リンク経由で送信し、そうでない場合は低速リンク経由で送信します。local tried_fast 、tried_slow : BOOLEAN do if tried_fast then tried_slow := True send_slow ( m ) else tried_fast := True send_fast ( m ) end rescue if not tried_slow then retry end end   
  

    

    
       
      
  
       
      
  

     
     
  

ブール型のローカル変数は、開始時に False に初期化されます。 が send_fast失敗した場合、本体 (do節) が再度実行され、 が実行されますsend_slow。 のこの実行がsend_slow失敗した場合、節は(最後の に 節がないため)rescue最後まで実行され、ルーチンの実行全体が失敗します。 retryelseif

このアプローチには、「正常」なケースと「異常」なケースを明確に定義できるという利点があります。例外を引き起こす異常なケースとは、ルーチンが契約を履行できないケースです。このアプローチでは、役割の明確な分担が定義されます。do節 (通常の本体) は、ルーチンの契約を達成するか、達成しようとします。rescue節は、コンテキストを再確立して、成功する可能性がある場合はプロセスを再開しますが、実際の計算は実行しません。

Eiffel の例外にはかなり明確な哲学があるが、Kiniry (2006) は「言語定義の一部である例外は INTEGER 値で表され、開発者が定義した例外は STRING 値で表されます。[...] さらに、例外はオブジェクトではなく基本値であるため、ヘルパー ルーチンで表現されるものを超える固有のセマンティクスはなく、ヘルパー ルーチンは、実際の表現オーバーロードのため、絶対確実なものではありません (たとえば、同じ値の 2 つの整数を区別することはできません)。」と、その実装を批判しています。^[3]

現代のアプリケーションは、例外処理戦略を検討する際、多くの設計上の課題に直面します。特に現代のエンタープライズレベルのアプリケーションでは、例外はプロセス境界やマシン境界を越えることがよくあります。堅実な例外処理戦略を設計する上で重要なのは、プロセスのソフトウェア部分では経済的に処理できないほどプロセスが失敗したことを認識することです。^[27]

例外がスローされてキャッチされない場合（操作上、適用可能なハンドラが指定されていない場合に例外がスローされます）、キャッチされない例外はランタイムによって処理されます。これを行うルーチンはキャッチされない例外ハンドラ。^[28][29]最も一般的なデフォルトの動作は、プログラムを終了し、コンソールにエラーメッセージを出力することです。通常、このエラーメッセージには、例外の文字列表現やスタックトレース。^[28][30][31]例外がランタイムに到達する前にキャッチするトップレベル（アプリケーションレベル）のハンドラ（たとえばイベントループ^[28][32]

キャッチされない例外によってプログラムが異常終了する可能性がある場合でも(例外がキャッチされない場合、特に部分的に完了したトランザクションをロールバックしなかったり、リソースを解放しなかったりすると、プログラムが正しく動作しない可能性があります)、ランタイム (プログラムの実行を制御している) によってプロセスの正常なシャットダウンが保証されるため、プロセスは正常に終了します (ランタイムが正しく動作していると仮定)。

マルチスレッド プログラムでは、スレッド内でキャッチされない例外が発生すると、プロセス全体ではなく、そのスレッドのみが終了されることがあります (スレッド レベルのハンドラー内でキャッチされない例外は、トップ レベルのハンドラーによってキャッチされます)。これは、サーバーにとって特に重要です。たとえば、 (独自のスレッドで実行されている)サーブレットを、サーバー全体に影響することなく終了できます。

このデフォルトのキャッチされない例外ハンドラは、グローバルまたはスレッドごとにオーバーライドできます。たとえば、キャッチされない例外の代替ログ記録やエンドユーザーレポートを提供したり、キャッチされない例外が原因で終了したスレッドを再起動したりすることができます。たとえば、Java では、これは を介し​​て単一のスレッドに対してThread.setUncaughtExceptionHandler、 を介してグローバルに実行されますThread.setDefaultUncaughtExceptionHandler。Python では、 を変更することによって実行されますsys.excepthook。

Javaは、チェック例外の概念を導入しました。 ^{[33] [34]チェック例外は、例外の特別なクラスです。メソッドが発生させる可能性のあるチェック例外は、メソッドの}シグネチャの一部でなければなりません。たとえば、メソッドが をスローする可能性がある場合IOException、メソッドシグネチャでこの事実を明示的に宣言する必要があります。そうしないと、コンパイル時エラーが発生します。Hanspeter Mössenböckによると、チェック例外は不便ですが、より堅牢です。^{[35]チェック例外は、}コンパイル時に、特定のアプリケーションで 実行時に未処理の例外が発生する頻度を減らすことができます。

Kiniry は次のように書いています。「Java プログラマーなら誰でも知っているように、try catch典型的な Java アプリケーションのコード量は、チェック例外を持たない他の言語で明示的な形式パラメータと戻り値のチェックに必要な同等のコード量よりも大きくなることがあります。実際、現場の Java プログラマーの間では、チェック例外の処理はドキュメントの作成と同じくらい不快な作業であるという意見が一般的です。そのため、多くのプログラマーがチェック例外を「嫌う」と報告しています。」^[3] Martin Fowlerは次のように書いています。「... 全体として例外は良いと思いますが、Java のチェック例外は手間がかかるものです。」^[36] 2006 年現在、Java に続いてチェック例外を追加した主要なプログラミング言語はありません。^[36]たとえば、C#では例外仕様の宣言は不要または許可されていません。Eric Gunnerson は次のように投稿しています。^{[37] [3] [36]}

「小規模なプログラムを調査すると、例外仕様を要求すると開発者の生産性とコード品質の両方が向上する可能性があるという結論に至りますが、大規模なソフトウェア プロジェクトの経験では、生産性が低下し、コード品質はほとんど向上しないかまったく向上しないという異なる結果が示されています。」

アンダース・ヘルスバーグは、チェック例外に関する2つの懸念について述べている。^[38]

• バージョン管理: メソッドは例外 X と Y をスローするように宣言されている場合があります。コードの以降のバージョンでは、メソッドから例外 Z をスローすることはできません。これは、新しいコードが以前の使用と互換性がなくなるためです。チェック例外では、メソッドの呼び出し元が throws 句に Z を追加するか、例外を処理する必要があります。または、Z が誤って X または Y として表現される可能性があります。
• スケーラビリティ: 階層型設計では、各システムに複数のサブシステムが存在する場合があります。各サブシステムは複数の例外をスローする場合があります。各親システムは、その下のすべてのサブシステムの例外を処理する必要があるため、処理する例外の数は指数関数的に増加します。チェック例外では、これらの例外すべてを明示的に処理する必要があります。

これらの問題を回避するために、ヘルズバーグ氏によると、プログラマーは宣言を使用して機能を回避する手段に頼っている。別の回避策は、ハンドラーを使用することである。^{[38]これは、}番組のキャッチフレーズ「Gotta Catch 'Em All!」にちなんで、キャッチオール例外処理またはポケモン例外処理と呼ばれています。 ^[39] Javaチュートリアルでは、キャッチオール例外処理は「ハンドラーが意図していない」例外をキャッチする可能性があるため推奨されていません。 ^[40]さらに推奨されていない別の回避策は、すべての例外をサブクラス化することです。^[41]推奨される解決策は、キャッチオールハンドラーまたはthrows句を使用することですが、汎用スーパークラスではなく、スローされる可能性のあるすべての例外の特定のスーパークラスを使用します。別の推奨される解決策は、呼び出されたメソッドの抽象化レベルに適した例外タイプを定義および宣言し、^[42]例外チェーンを使用して低レベルの例外をこれらのタイプにマップすることです。 throws Exceptiontry { ... } catch (Exception e) {}RuntimeExceptionException

チェック例外の起源は、 CLUプログラミング言語の例外仕様の概念に遡ります。 ^[43]関数は、その型にリストされている例外のみを発生させることができますが、呼び出された関数から漏れた例外は、failureコンパイル時エラーになるのではなく、自動的に唯一の実行時例外に変換されます。^[44]その後、Modula-3にも同様の機能が追加されました。^[45]これらの機能には、チェック例外の概念の中心となるコンパイル時のチェックは含まれていません。^[43]

C++ プログラミング言語の初期のバージョンには、例外仕様と呼ばれる、チェック例外に似たオプションのメカニズムが含まれていました。デフォルトでは、どの関数も例外をスローできましたが、関数シグネチャに追加された句によって制限され、関数がスローできる例外を指定できました。例外仕様はコンパイル時には強制されませんでした。違反すると、グローバル関数が呼び出されました。^[46] 関数が例外をスローしないことを示す空の例外仕様を指定することもできます。例外処理が言語に追加されたときにこれがデフォルトにならなかったのは、既存のコードに多くの変更が必要になり、他の言語で書かれたコードとの相互作用が妨げられ、プログラマがローカルレベルであまりにも多くのハンドラを記述する誘惑に駆られるためです。^[46]ただし、空の例外仕様を明示的に使用すると、C++ コンパイラは、関数内で例外処理が行われる可能性がある場合には実行できない、重要なコードおよびスタックレイアウトの最適化を実行できます。^[23] 一部のアナリストは、C++ で例外仕様を適切に使用することは難しいと考えていました。^{[47]この例外仕様の使用は}C++98とC++03に含まれていましたが、2012年のC++言語標準（C++11）で非推奨となり、 ^[48] C++17で言語から削除されました。例外をスローしない関数は、キーワードで表すことができます。 throwstd::unexpectednoexcept

OCamlプログラミング言語には、キャッチされない例外アナライザーが存在します。^[49]このツールは、発生した例外のセットを拡張型シグネチャとして報告します。ただし、チェック例外とは異なり、このツールは構文注釈を必要とせず、外部ツールです（つまり、例外をチェックせずにプログラムをコンパイルして実行することができます）。

例外処理ルーチンの目的は、コードがエラー状態を処理できることを保証することです。例外処理ルーチンが十分に堅牢であることを確立するには、ソフトウェア障害注入や突然変異テスト(ファズテストとも呼ばれる) によって作成できるような、無効または予期しない入力を広範囲に渡ってコードに提示する必要があります。例外処理ルーチンを記述するのが最も難しいソフトウェアの 1 つはプロトコル ソフトウェアです。これは、堅牢なプロトコル実装が、関連する仕様に準拠しない入力を受信できるように準備する必要があるためです。

ソフトウェア開発ライフサイクル プロセス全体を通じて意味のある回帰分析を確実に実施するには、例外処理テストを高度に自動化し、テスト ケースを科学的かつ繰り返し可能な方法で生成する必要があります。このようなテストを実行する市販のシステムがいくつかあります。

Javaや.NETなどのランタイム エンジン環境には、ランタイム エンジンに接続し、対象の例外が発生するたびに、例外がスローされた時点でメモリ内に存在していたデバッグ情報 (コール スタックとヒープ値) を記録するツールが存在します。これらのツールは、自動例外処理ツールまたはエラー インターセプト ツールと呼ばれ、例外の「根本原因」情報を提供します。

非同期例外は、 Ctrl+C を押してプログラムを中断する、シグナルを受信する、別の実行スレッドから「停止」や「一時停止」などの中断メッセージを送信するなど、別のスレッドまたは外部プロセスによって発生するイベントです。^{[50] [51]}同期例外は特定のステートメントで発生しますがthrow、非同期例外はいつでも発生する可能性があります。したがって、非同期例外処理は、非同期例外がないことを証明できないため、コンパイラによって最適化することはできません。また、リソース リークを回避するために、クリーンアップ操作中に非同期例外をブロックする必要があるため、正しくプログラムすることは困難です。

プログラミング言語は、通常、非同期例外処理を避けたり制限したりします。たとえば、C++ はシグナル ハンドラからの例外の発生を禁止し、Java は、あるスレッドが別のスレッドを停止できるようにするために使用されていた ThreadDeath 例外の使用を非推奨にしました。^[52]もう 1 つの機能は、プログラムの特定の操作中にのみ非同期例外を発生させる半非同期メカニズムです。たとえば、Java の は、スレッドが をスローする操作を呼び出したときにのみスレッドに影響します。^[53]同様の POSIX API には競合状態があり、安全に使用することが不可能です。^[54]Thread.interrupt()InterruptedExceptionpthread_cancel

Common Lisp、R、^[55] Dylan、Smalltalkには、前述の例外処理システムを網羅する条件システム^[56]（Common Lisp条件システムを参照）がある。これらの言語や環境では、条件（ Kent Pitmanによると「エラーの一般化」）の出現は関数呼び出しを意味し、例外ハンドラの後半でのみスタックをアンワインドする決定が行われる可能性がある。

条件は例外を一般化したものである。条件が発生すると、適切な条件ハンドラが検索され、スタック順に選択されて条件を処理する。エラーを表さない条件は、まったく処理されなくても安全である。その唯一の目的は、ユーザーにヒントや警告を伝えることである。^[57]

これは、例外処理のいわゆる再開モデルに関連しています。このモデルでは、一部の例外は継続可能と言われています。つまり、ハンドラーで修正アクションを実行した後、例外を通知した式に戻ることができます。条件システムは次のように一般化されています。重大でない条件 (継続可能な例外とも呼ばれます) のハンドラー内では、通知式と条件ハンドラーの間にある定義済みの再開ポイント (再開とも呼ばれます) にジャンプすることができます。再開は、何らかの語彙環境に対して閉じられた関数であり、プログラマーは、条件ハンドラーを完全に終了するか、スタックを部分的にでも巻き戻す前に、この環境を修復することができます。

一例として、 PL/I のENDPAGE条件が挙げられます。ON ユニットは、次のページのページ トレーラー行とヘッダー行を書き込み、その後、中断されたコードの実行を再開します。

さらに、条件処理はメカニズムとポリシーの分離を提供します。再起動は、エラーから回復するためのさまざまなメカニズムを提供しますが、特定の状況でどのメカニズムが適切であるかを選択するわけではありません。これは条件ハンドラーの領域であり、条件ハンドラーは（高レベルのコードに配置されているため）より広いビューにアクセスできます。

例: 単一のsyslogファイル エントリを解析するライブラリ関数があるとします。エントリが不正な形式である場合、この関数はどのような処理を実行する必要がありますか? 同じライブラリがさまざまな目的のプログラムに展開される可能性があるため、正しい答えは 1 つではありません。対話型のログ ファイル ブラウザーでは、エントリを解析せずに返してユーザーが確認できるようにすることが正しい処理である可能性があります。ただし、自動ログ要約プログラムでは、読み取り不可能なフィールドに null 値を指定して、不正なエントリが多すぎる場合はエラーで中止することが正しい処理である可能性があります。

つまり、この質問に対する回答は、汎用ライブラリ関数にはわからないプログラムのより広範な目標に基づいてのみ可能です。とはいえ、エラー メッセージで終了することが正しい回答となることはめったにありません。そのため、関数は、単にエラーで終了するのではなく、さまざまな継続方法を提供する再起動を確立する場合があります。たとえば、ログ エントリをスキップする、読み取り不可能なフィールドに既定値または null 値を提供する、ユーザーに不足している値を要求する、スタックをアンワインドしてエラー メッセージで処理を中止するなどです。提供される再起動は、エラーから回復するために使用できるメカニズムを構成します。条件ハンドラによる再起動の選択によって、ポリシーが提供されます。

例外処理はソフトウェアで正しく処理されないことが多く、例外の発生源が複数ある場合は特にそうです。500万行の Java コードのデータフロー解析では、1,300 を超える例外処理の欠陥が見つかりました。 ^[13] Weimer と Necula は、他の研究者による複数の先行研究 (1999～2004 年) と独自の結果を引用して、例外の重大な問題は「プログラマが理解しにくい隠れた制御フロー パスを作成する」ことだと書いています。^{[13] : 8:27}「try-catch-finally は概念的には単純ですが、言語仕様 [Gosling 他 1996] で最も複雑な実行記述を持ち、公式の英語記述では 4 レベルのネストされた「if」を必要とします。つまり、プログラマが見落としがちなコーナー ケースが多数含まれています。」^{[13] : 8:13～8:14}

例外は非構造化フローであるため、リソース リーク(ミューテックスによってロックされたセクションからの脱出や、一時的にファイルを開いたままにするセクションからの脱出など) や不整合状態のリスクが高まります。例外が発生した場合のリソース管理にはさまざまな手法がありますが、最も一般的なのは、 dispose パターンと何らかの形式の unwind 保護 (finally句など) を組み合わせたもので、これにより、制御がコード セクションから出るときにリソースが自動的に解放されます。

トニー・ホーアは1980 年にAda プログラミング言語について次のように述べている。「... 機能や表記規則が多すぎて、その多くは不必要であり、例外処理など、危険なものもあります。[...] この言語を現状のままで信頼性が極めて重要なアプリケーションに使用することは許可しないでください。[...] プログラミング言語のエラーによって次に道を踏み外すロケットは、金星への無害な旅をしている探査宇宙ロケットではないかもしれません。それは、私たちの都市の 1 つで爆発する核弾頭かもしれません。」^[58]

Goの開発者は、try-catch-finallyイディオムは制御フローを難読化すると考えており^[59]、例外のようなpanic/recoverメカニズムを導入しました。^[60]は 関数内のコードブロック内からのみ呼び出すことができるという点でと異なり、ハンドラはクリーンアップと関数の戻り値の変更しかできず、関数内の任意のポイントに制御を戻すことはできません。^[61]ブロック自体は句と同様に機能します。 recover()catchdeferdeferfinally

• 自動化された例外処理
• 継続
• 防御プログラミング
• 例外安全性
• オプション型と結果型、例外なしで関数型プログラミングでエラーを処理する代替方法

• Gabriel, Richard P. ; Steele, Guy L. (2008). 言語進化のパターン(PDF) . LISP50: Lisp 50周年記念。pp. 1–10. doi :10.1145/1529966.1529967. ISBN 978-1-60558-383-9。
• Goodenough, John B. (1975a)。構造化例外処理。プログラミング言語の原理に関する第 2 回 ACM SIGACT-SIGPLAN シンポジウム議事録 - POPL '75。pp. 204–224。doi : 10.1145/512976.512997。
• Goodenough, John B. (1975). 「例外処理: 問題と提案された表記法」(PDF) . Communications of the ACM . 18 (12): 683–696. CiteSeerX  10.1.1.122.7791 . doi :10.1145/361227.361230. S2CID  12935051.
• Stroustrup, Bjarne (1994)。C ++ の設計と進化(第 1 版)。マサチューセッツ州レディング: Addison- Wesley。ISBN 0-201-54330-3。
• White, Jon L (1979 年 5 月)。NIL - 展望(PDF)。1979 年 Macsyma ユーザーズ カンファレンスの議事録。