9

古いコードをリファクタリングしていますが、解決したいことの 1 つは、エラーの処理方法です。私は例外とその仕組みについてよく知っていますが、私が処理しようとしている状況に対して例外が最適な解決策であるかどうかは完全にはわかりません。

このコードでは、物事が検証されない場合、スタックをアンワインドする理由もメリットもありません。終わったね。船を救おうとしても意味がありません。これは、Sun Grid Engine を介して並行して実行される非対話型のコードだからです。ユーザーは介入できません。さらに、これらの検証の失敗は、実際には例外的な状況を表しているわけではありません。彼らは期待されています。

では、これにどう対処するのが最善でしょうか? 私が望んでいると確信していないことの 1 つは、失敗する可能性があるすべてのクラス メソッドの終了点です。それは維持できないようです。私が間違っている？このようなコードの障害点で、exit()または単に呼び出すことは許容される慣行ですか? abort()それとも、メインの一般的な catch ステートメントまで例外をスローする必要がありますか? 利点は何ですか？

4

4 に答える 4

4

エラーを正常に処理できない場合は、プログラムを終了してもかまいません。あなたができることはいくつかあります：

  • abort()コア ダンプが必要な場合は呼び出します。
  • exit()に登録されているルーチンを実行する機会を与えたい場合に呼び出しますatexit()(グローバル C++ オブジェクトのデストラクタを呼び出す可能性が最も高い)。
  • _exit()プロセスをすぐに終了するために呼び出します。

自分が何をしているのかを理解し、他の選択肢を知り、その道を進んで選択する限り、これらの機能を使用することに何の問題もありません。結局のところ、それがそれらの機能が存在する理由です。したがって、エラーを処理したり、エラーが発生したときに何か他のことをしたりする意味がないと思う場合は、先に進んでください。私がおそらく行うことは、何らかの有益なメッセージを (たとえば syslog に) ログに記録して、 を呼び出すこと_exitです。ロギングが失敗した場合 -abort終了に沿ってコアを取得するために呼び出します。

于 2012-05-21T14:31:17.567 に答える
4

メインでキャッチされる例外をスローしてから終了すると、RAII リソース オブジェクトがクリーンアップされます。ほとんどのシステムでは、多くのリソース タイプでこれは必要ありません。OS はメモリ、ファイル ハンドルなどをクリーンアップします (ただし、メモリを解放できないとシステムが再起動するまでメモリが割り当てられたままになるシステムを使用したことがあるため、プログラムの終了時にリークすることはお勧めできません。)

ただし、ネットワークやデータベース接続、または運転中の安全にシャットダウンする必要がある機械装置など、クリーンに解放したいリソースの種類は他にもあります。アプリケーションがそのようなものをたくさん使用する場合は、例外をスローしてスタックをメインに戻し、終了することをお勧めします。

したがって、適切な終了方法はアプリケーションによって異なります。アプリケーションが安全であることを認識している場合、_Exit()、abort()、exit()、または quickexit() を呼び出すことは完全に合理的です。(ライブラリ コードはこれらを呼び出すべきではありません。ライブラリを使用するすべてのアプリケーションにとって安全かどうかは明らかにライブラリにはわからないためです。)の場合、アプリケーションは atexit() または at_quick_exit() を介してそのクリーンアップ コードを登録できます。

したがって、基本的には、クリーンアップが必要なものを決定し、それを文書化し、実装し、テスト済みであることを確認してください。

于 2012-05-21T14:59:59.143 に答える
2

グローバル関数を呼び出すことをお勧めします

void stopProgram() {
  exit(1);
}

後で動作を変更できるため、保守が容易です。

于 2012-05-21T14:21:15.980 に答える
1

あなたが指摘したように、コード全体でexitorをabortスローすることは維持できません...さらに、将来的には、エラーから回復したり、単にエラーをより適切な方法で処理したりできるメカニズムが存在する可能性がありますこの機能をすでにハードコーディングしている場合、元に戻すのは非常に困難です。

キャッチされた例外をスローすることはmain()、この時点で最善の策です。これにより、将来、エラーから回復したり、別の方法で処理したりできる別のシナリオでコードを実行した場合に柔軟性が得られます。さらに、デバッグ サポートなどを追加することを決定した場合、例外をスローすると、ログ機能を実装し、プログラムの終了を決定する前に、ソフトウェア内の分離された保守可能なポイントからプログラムの状態を記録する場所が得られるため、役立ちます。

于 2012-05-21T14:24:34.500 に答える