例外オブジェクトをサポートする言語 (Java、C#) では、いつエラー コードを使用するのが適切ですか? 一般的なエンタープライズ アプリケーションでエラー コードを使用することは適切ですか?
多くのよく知られているソフトウェア システムでは、エラー コード (および対応するエラー コード参照) が使用されています。いくつかの例には、オペレーティング システム (Windows)、データベース (Oracle、DB2)、およびミドルウェア製品 (WebLogic、WebSphere) が含まれます。エラー コードにはどのような利点がありますか? エラーコードを使用することの欠点は何ですか?
プログラム内では、エラー コードの代わりに常に例外を使用する必要があります。ただし、例外はプログラムを超えて伝播することはできません。エラーがプログラムから出なければならないときはいつでも、エラー メッセージまたはエラー コードが残されます。
コードのない人間が操作するエラーメッセージが常に表示される単純なものについては、問題ありません。エラーコードを表示せずに「ファイルが見つかりません」と言うことができます。ただし、相手側の別のコンピューターである可能性がある場合は、さらにエラー コードを指定する必要があります。「ファイル <x> が見つかりません」に変更するときに、他のシステムを壊したくありません。
ある状況を除いて、.Net でエラー コードを使用したことはないと思います。別のアプリから呼び出されることがわかっているコンソール アプリケーションを作成していたときです。この他のアプリは、コンソール アプリがいつ失敗したか、何が問題だったかを知る必要がありました。そのため、適切な例として、自分のプログラムが他のプログラムから呼び出されることがわかっていて、それらがエラーを理解するための構造化された方法が必要な場合があります。
とはいえ、私は当時 .NET の初心者であり、それ以来エラー コードを使用したことはありません。
補足として、Windows の人間として、エラー コードを入力して KB 記事を作成できるのはうれしいことです。したがって、エラー コードと優れたドキュメントおよびそれを見つける機能を組み合わせることで、ユーザーからの好感を得ることができます。
Web サービス インターフェイスでは非常に一般的です。説明付きのコードを返すのは非常に簡単で標準的です。
ほとんどのシナリオは昔ながらのものであることに同意します
最大の欠点はコードの品質だと思います。メソッド パラメーターや戻り値を使用せずに例外がバブルされている間、エラー コードを管理するには、より複雑なロジックを追加する必要があります。
また、返されたコードが成功したかどうかを確認するために「IF」を追加する必要がありますが、例外はエラー処理ブロックに直接送られます。
私はスタックオーバーフローの初心者ですが...
エラーコードは、状況を修正するためにある種のエンドユーザーが関与する必要がある誤った状況に対処するために使用または役立つ傾向があると思います。あなたのコードが別の開発者によって保守される場合、例外が有効です。ただし、問題がある状況では:
アプリケーションが実行されている環境で
アプリと他のエンティティ (Web サーバー、データベース、ソケットなど) との間の通信
デバイスまたはデバイス ドライバーが示す (ハードウェア障害でしょうか?)
エラーコードは理にかなっているかもしれません。たとえば、アプリがエンドユーザーに代わってデータベースにログインしようとしたが、認証のために DB に到達できなかった (DB がオフラインで、ケーブルが接続されていない) 場合、エラー コード/説明の組み合わせがエンドユーザーに役立つ可能性があります。ユーザーが問題を修正します。
ここでも、ソース コード (従来のデバッグおよびテスト手法) に触れて変更できる開発者/エンジニア レベルで、例外を使用します。
お役に立てれば...
--jqpdev
エラーコードは国際化できるため、エラーをユーザーに伝える必要がある場合にエラーコードをよく使用します。たとえば、コンパイラでは、ユーザー コードにエラーがある場合、コンパイラのバックエンドでエラーを通知できますが、フロントエンドではエラーをユーザーが使用できるようにカルチャ/言語固有の文字列にローカライズできます。ただし、この目的には、生の整数よりも列挙型の方が適している場合があります。
アプリの「エラー報告」フレームワークの作成にもそれらを使用しました。例外がスローされると、例外はエラー コードとともにスローされ、例外が発生すると、(ログと共に) 中央サーバーに送信されました。このコードはデータベースの整理に役立ち、特定のエラーに関連するログを調べることができました。
最後に、他のいくつかの回答で述べたように、エラー コードは Google にとって簡単で言語に依存しないため (Windows エラー コード/MS KB の記事を考えてください)、何が問題なのかを説明したエラー コードの方が、技術的な製品。
エラー コードの考え方は便利ですが、IMO では、例外メンバーとして、または IErrorReporter インターフェイスへのパラメーターとして、またはメソッドの戻り値としてよりも多くのものとして属しています。
エラー コードは、関数が呼び出し元に問題が発生したことを伝える唯一の方法が、返される値の 1 つまたは複数の値に特別な意味を割り当てることであった時代に設計されました。その特別な値を返すために利用できます。
たとえば、C の「get character」ルーチンは次の文字値を ASCII で返しますが、何らかの理由で問題が発生した場合は負の値を返します。次に、このエラー状況を処理できるように呼び出し元に戻る責任があり、それが返される必要があります。
Exception メカニズムは、この「これは緊急事態です。何か問題を処理できるようになるまで、コードから戻る必要があります」を処理するための洗練された方法です。エラーコードはこれより劣ります。
C# は、おそらく Java も同様に、より優れた例外処理制御フロー (finally キーワード) をサポートしています。これにより、エラー コードを使用するよりも処理が少し楽になります。例外オブジェクトには、あらゆるレベルの詳細を含めることができますが、エラー コードよりもはるかに多くの情報を含めることができます。そのため、例外オブジェクトの方がはるかに実用的ですが、エラー コードの方が適切な珍しいケースに遭遇する可能性があります。
FWIW、C++ は例外オブジェクトもサポートしています。C++ が finally キーワードをサポートしているとは思いません (ただし、新しい C++ は何でも構いません) が、C++ では、catch ハンドラー内で戻るなどのことも避ける必要があります。
エラーコードは昔ながらのものです。それらはまったく価値がありません。
エラー コードの唯一の可能な値は、非常に具体的な状況を識別できることです。例外をスローできるコード ベース内の各ポイントにコードを含めることができます。これにより、問題が何であるかを非常に正確に絞り込むことができます。
しかし、誰もそのレベルの詳細を気にしません。誰がそのような混乱を維持したいのですか。「条件AとBであるが、状態SのためにCではない」などのコードが残ります。それが何を意味するのかを正確に理解しようとするのは、価値があるよりも多くの努力です。スタック トレースは、プログラムのどこで問題が発生したかを知る上でより価値があります。
例外が広く普及する前に、コンピューターのプログラミングを学びました。代わりに例外があったことをとてもうれしく思います。
エラー コードは、ユーザーに送信する場合に使用します。そうでない場合は、例外を使用します。
私は、他の (リモート) アプリケーションによって消費される多くの Web サービスを作成してきました。リクエストがうまくいかない場合、顧客は多かれ少なかれコードを取得することを主張します。そのため、何が問題なのかを見つけるために恐ろしい文字列比較を行う必要はありません。
この種の動作の良い例として、HTTP 結果コードを取り上げます。「200」は幸せを意味し、「300」はどちらの方向にも進む可能性があり、「400」または「500」はおかしくなり始めることを意味します。