多くの言語はハードウェアとしてCPU例外や、I/Oに対する入出力の（ハードウェア的）例外と、多くは
復帰可能なエラー分岐処理にて、プログラミング言語で「包括的に捕捉して後処理」するためにある。
例外の反対者はResult/Option/(Either)のようなものがあるのに、なぜ言語に例外を取り入れて、信頼性を
低下させるような隠された制御フローを導入するのかと主張します。

しかし例えばファイルへの出力で"fwrite"ではOSの上層では実際に書き込まれず、"fclose"で書き込まれたり
あるいは"fflush"でメモリー上とディスクが同期されるなどは、同期的な、従来の戻り値を確認しただけでは
正確な判断ができない。（これは言語のライブリーがBufferを使用しているとは別の話、たとえばディスク
容量が足りなくなった場合など、意図するプログラムは失敗する可能性があります。）
またResultなどが使用できるの場合は、ハードウェアやIOに依存しない場合にできるだけです。他にも、不正な
ゼロ除算などの発生は、カーネルでも、組み込みでも、CPU例外に対しては特定の例外の種類によりあらかじめ
決められたアドレスに強制的にジャンプします。C言語自身はCPUの挙動を定義していませんので、この制御の
フローの移動はCプログラミング言語の機能ではなくCPUメーカーの実装です。
つまり、標準のC自体だけでは、統一的にエラー処理を記述するということ自体が出来ていませんし、実行制御
フロー記述し完全掌握してコントロールするという事自体があやふやです。
（ゼロ除算でジャンプしなくてHALTするようなCPUがあるかもしれませんが知りません）