エラーメッセージに関する一般的なコンセンサスは何だったのだろうかと思っていました。それらはどのくらい詳細にすべきですか？
大きすぎる、小さすぎる、小数、文字列などの数値を入力すると、別のエラーメッセージが表示されるプロジェクトに取り組んできました。これは、問題がどこで発生したかを正確に把握しているため、ユーザーにとって非常に便利でした。 、しかし、エラー処理コードは、サイズが実際のビジネスロジックに匹敵し始め、独自のバグのいくつかを開発し始めました。
反対側では、次のような非常に一般的なエラーが発生するプロジェクトに取り組んできました。
コンパイルに失敗した理由3
言うまでもなく、理由3はリンクエラーを意味することが判明したため、ほとんどまったく役に立たなかった。
では、妥協点はどこにあるのでしょうか。十分に説明的なエラーメッセージを追加したかどうかはどうすればわかりますか？ユーザーがどこで間違っているのかを理解できるかどうかはどうすればわかりますか？
エラーメッセージには、ユーザーと開発者の2つのターゲットオーディエンスが考えられます。
通常、メッセージはユーザーをターゲットにする必要があります。
o問題の原因は何ですか。
oプログラムが問題を回避できない理由
oユーザーが問題を回避するためにできること。
o問題を報告する方法。
問題を報告する場合は、レポートにできるだけ多くのプログラムコンテキスト情報を含める必要があります。
oモジュール名
o関数名
o行番号
o問題の一般的な領域で関心のある変数
oコアダンプでさえあるかもしれません。
正しいオーディエンスをターゲットにします。
何が起こったのか、そしてユーザーの選択肢は何なのかをできるだけ短い言葉で伝える必要があります。エラーメッセージが長いほど、ユーザーがエラーメッセージを読む可能性は低くなります。同様に、短いエラーメッセージは不可解で役に立たない。長さの点でスイートスポットがあり、それは状況ごとに異なります。
短すぎる：
無効入力。
長すぎる：
192.168.0.1などの正しくフォーマットされたIPアドレスを入力してください。IPアドレスは、ネットワーク上のコンピューターを識別するために使用される番号です。
ちょうどいい：
有効なIPアドレスを入力してください。
コードの膨張に関する限り、少し余分なコードを使用すると、ユーザーがサポートに電話したり、イライラしたりするのを防ぐことができれば、それは良い投資です。
エラーメッセージには、ユーザーに表示されるメッセージとプログラマーに表示されるエラーの2種類があります。
「ユーザーがどこで間違っているのかを理解できるかどうかをどうやって知ることができますか？」これらのメッセージはユーザーにのみ表示され、あまり技術的なメッセージでCOMPILE FAILED REASON 3はなく、一般的なエンドユーザーのエラーメッセージではないと思います。これはプログラマーが目にするものです（ユーザーは通常、コンパイルを行いません）。
したがって、それが表示されるのがユーザーの場合：
最後に、ユーザーに簡単でわかりやすいコマンドをいくつか提供します（「再試行」、「キャンセル」など）。
エラーメッセージに関する本当の問題は、それらを表示する必要があるかどうかです。多くのエラーメッセージがユーザーに表示されますが、それらを修正する方法はありません。
エラーを修正する方法がある限り、ユーザーが自分でエラーを修正できるように十分な情報をユーザーに提供します。彼らが自分でそれを修正することができない場合、クラッシュの技術的な理由を彼らに伝える理由はありますか？後でトラブルシューティングするためにファイルに記録するだけではありません。
必要なだけ詳細に;）
私はそれが賢いお尻の答えのように聞こえることを知っていますが、これの多くはあなたのターゲットオーディエンスとエラーの種類に依存します。無効なユーザーエントリによって引き起こされたエラーについては、有効なエントリを構成するものを表示できます。ユーザーが制御できないエラーの場合、一般的な「作業中です」タイプのメッセージで十分な場合があります。
長さに関するJonBのコメントにも同意します。
エラーメッセージは詳細である必要がありますが、明確です。これは、複数のレベルからのエラーメッセージを組み合わせることで実現できます。
Failed to save the image
Permission denied: /foo.jpg
ここには2つのレベルがあります。もっとあるかもしれません。最初に全体像を伝え、次に詳細を伝えます。順序は、最初にほとんどの人に理解されている部分があり、次にほとんどの人に理解されていない部分がありますが、両方とも表示できます。
さらに、修正の提案があるかもしれません。
私はもっと詳細に誤りを犯しますが、あなたはあなた自身の質問に答えたと思います。コードの肥大化を回避するには、コード/エラーメッセージで有用な情報を提供しますが、ドキュメントで、またはヘルプファイルやFAQで詳細を提供できます。
私の意見では、情報が少なすぎるとさらに悪いことになります。
豊富なイントロスペクションまたはその他の機能を備えた言語を使用している場合は、チェックに失敗した行を含むログが役立ちます。その後、ユーザーはテクニカルサポートに転送するか、詳細情報を取得できます。これは追加のコード膨張ではなく、独自のコードを使用して情報を提供します。