標準化されたエラーの分類と処理

Question

エラー/例外を「適切に」分類および処理する方法を標準化する必要があります。

私は現在、エラー番号、重大度コード、位置情報、追加情報文字列を渡す関数にエラーを報告するプロセスを使用しています。この関数は、エラーが致命的でアプリが停止する必要がある場合はブール値 true を返し、それ以外の場合は false を返します。この関数はプロセスの一部として、ユーザーへの視覚的なフィードバックとは別に、ある重大度レベルを超えるエラーをファイルに記録します。

エラー番号は、エラーのタイプを説明する文字列の配列にインデックスを付けます (例: 「ファイル アクセス」、「ユーザー入力」、「スレッド作成」、「ネットワーク アクセス」など)。重大度コードは 0、1、2、または 4 のバイナリ OR です。0=情報、1=user_retry、2=cannot_complete、4=cannot_ continue です。Location-info はモジュールと関数、Extra-info はパラメータとローカル変数の値です。

これをライブラリに入れてすべてのアプリで再利用できる標準的なエラー処理方法にしたいと考えています。私は主に Linux で C/C++ を使用していますが、結果として得られるライブラリを他の言語/プラットフォームでも使用したいと考えています。

• アイデアは、エラータイプの配列を拡張して、特定の重大度レベルのデフォルトの動作を示すことですが、これはアクションになり、ユーザーにオプションを提供しない必要がありますか？

• または：このような拡張機能は、ユーザーが選択する必要があるオプションのサブアレイである必要がありますか？これの問題は、オプションが必要に応じて、エンドユーザーを完全に困惑させる可能性のある一般化プログラミング関連オプションであることです。

• または：エラー-LIBルーチンを使用する各アプリは、エラーまたはデフォルトの動作のいずれかの配列に沿って渡される場合ですが、これはライブラリの目的を打ち負かします...

• または：重大度レベルは各アプリで処理する必要がありますか？

または：何を指示してるんですか？エラーはどのように処理しますか?これを改善するにはどうすればよいでしょうか?

Answer 1

エラーをどのように処理するかは実際にはアプリケーションによって異なります。Web アプリケーションにはデスクトップ アプリケーションとは異なるエラー検出メカニズムがあり、どちらも非同期メッセージング システムとは大きく異なります。

そうは言っても、エラー処理の一般的な方法は、処理可能な可能な限り低いレベルで処理することです。これは通常、アプリケーション層または GUI を意味します。

重大度レベルが気に入っています。おそらく、さまざまなエラー出力プロバイダーと重大度レベルのプロバイダーを備えた、プラグ可能なエラー コレクション ライブラリを使用できるでしょう。

出力プロバイダーには、logginProvider や IgnoreErrorsProvider などを含めることができます。重大度レベルは通常、それが発生するプロジェクトの種類によって決定されるため、重大度プロバイダーはおそらく各プロジェクトによって実装されるものになります。(たとえば、ネットワーク接続の問題は、連絡先管理システムよりも銀行アプリケーションの方が深刻です)。