エラー/例外を「適切に」分類して処理する方法を標準化する必要があります。
私は現在、エラー番号、重大度コード、位置情報、および追加情報文字列を渡す関数にエラーを報告するプロセスを使用しています。この関数は、エラーが致命的でアプリが終了する必要がある場合はブール値の true を返し、それ以外の場合は false を返します。そのプロセスの一部として、ユーザーへの視覚的なフィードバックとは別に、関数は、特定の重大度レベルを超えるエラーをファイルに記録します。
エラー番号は、エラーのタイプを説明する文字列の配列にインデックスを付けます。たとえば、「ファイル アクセス」、「ユーザー入力」、「スレッド作成」、「ネットワーク アクセス」などです。重大度コードは、0、1、 2 または 4、0=情報あり、1=user_retry、2=cannot_complete、4=cannot_continue。location-info はモジュールと関数、Extra-info はパラメーターとローカル変数の値です。
これを、ライブラリに入れてすべてのアプリで再利用できるエラー処理の標準的な方法にしたいと考えています。私は主に Linux で C/C++ を使用していますが、結果のライブラリを他の言語/プラットフォームでも使用したいと考えています。
エラータイプの配列を拡張して、特定の重大度レベルのデフォルトの動作を示すことが考えられますが、これが実行されるアクションになり、ユーザーにオプションを与えないようにする必要がありますか?
または: そのような拡張機能は、ユーザーが選択する必要があるオプションのサブ配列であるべきですか? これに関する問題は、オプションが必然的に一般化されたプログラミング関連のオプションになり、エンドユーザーを完全に困惑させる可能性があることです。
または: error-lib ルーチンを使用する各アプリは、エラーまたはデフォルトの動作の独自の配列を渡す必要がありますが、これはライブラリの目的を無効にします...
または: 各アプリで重大度レベルを処理する必要がありますか?
または：あなたは何を提案しますか？エラーをどのように処理しますか? どうすればこれを改善できますか?