エラーに関するどの程度の情報をユーザーに表示する必要がありますか？
アプリケーションは常にエラーをスローする可能性があります。このようなエラーが発生した場合、アプリケーションに要求したことが成功しなかったため、ユーザーに通知する必要があります。
ただし、ユーザーにどのくらいの情報を提供する必要がありますか？私はほとんどの人がスタックトレースを表示しないことに同意していると思います（ スタックトレースをユーザーに表示されるエラーメッセージに含める必要がありますか？ ）。しかし、残りのエラーに関する質問は見つかりませんコンテンツまたはユーザーに表示するもの。
たとえば、例外をサポートする言語（.net、Java）には、共有する例外の種類、例外が発生した場所、および例外に合わせていくらか明確にするメッセージがあります。これもユーザーから非表示にする必要がありますか？それともとにかくこれを見せるべきですか？または、一般的なメッセージを表示する必要がありますか？または、根本的な例外が何であるかに基づいて、いくつかのメッセージの1つを表示する必要がありますか？
ユーザーに何を表示するか。これもユーザーから非表示にする必要がありますか？
ユーザーに何ができるかをユーザーに示します。
たとえば、一部のnullポインタ例外とユーザーエラーよりも多くのバグが原因でエラーが発生した場合、それらは何も異なることができないため、完全な説明は必要ありません。
それともとにかくこれを表示する必要がありますか？または、一般的なメッセージを表示する必要がありますか？
主なエラーメッセージの内容はほとんどのユーザーにとって無意味であるため、例外を表示。おそらく、ターゲットユーザーベースが開発者である場合は、常に完全なエラーとして情報を表示できます（自動テスト用の内部アプリケーションがある可能性があります）。しかし、一般的にユーザーはその知識があっても別のことはできません。
根本的な例外が何であるかに基づいて、いくつかのメッセージの1つを表示する必要がありますか？
最善の戦略は、次のことです。
- エラーをユーザーにとって意味のあるテキストに解釈します。
- これの一部は、「ユーザーが異なることを何ができるか？」です。
- 何も変わらない場合は、「予期しないエラーが発生しました」のように言います。
- 「オプション」の詳細なエラーの説明を追加する
- ユーザーにエラーレポートの送信を許可する（またはユーザーベースに応じて、これを自動的に実行する）
例
- 「ここに何が起こったのか」を示します（予期しないエラー）
- ユーザーに何をすべきかを指示します（メールを再開します。これを行うためのショートカットも含まれています）。
- 完全な技術エラーを知りたい場合は、「詳細を表示」も表示されます
- エラーエラーレポートが提出されたことを通知します（以下を参照）
場合によっては、エラーレポートを手動と自動のどちらにするかを指定できます。
それは、ユーザーが誰であるか、および情報を使用して何ができるかによって異なります。
一般的に、彼らが自分で解決できることに関する有用な情報のみを示すようにします。先頭に正規表現エラーがある40行のスタックトレースはあまり役に立ちません。もっと良いのは日付は "yyyy-mm-dd"のようにフォーマットする必要がありますというメッセージです。それ以外の場合、およびユーザーがエラーへの対応方法を知らない可能性があり、アプリケーションを使用したくない場合があります。これにより、より不可解で恐ろしいエラーが発生するのではないかと心配しています（そして、技術者以外のユーザーは、スタックに恐怖を感じることがあります）トレース）。そして、それはビジネスにとって悪いかもしれません。
他の開発者が使用する内部アプリケーションの場合、スタックトレースの表示について少しリラックスしますより便利なものに加えて、ユーザーがスタックトレースの表示を処理できることを知っているので、おそらく知っています。それについて何をすべきか。
技術者以外のユーザーの場合、スタックトレースを表示しても問題ないと思われるのは、問題を解決するためにneedである重大なエラー状況であり、コピーを要求され、スタックトレースを貼り付けて送信しますが、実際には、ログファイルを送信するように依頼するか、ユーザーに許可を求めた後、アプリケーションにログファイルを送信させることをお勧めします。ファイルを共有します。
ユーザーへのメッセージは、スローする新しい例外を作成するのと同じ方法で処理する必要があります。ユーザーが何をすべきかを決定するために必要な情報を提供します。
これはもちろんアプリケーションとユーザーベースに依存しますが、それはあなたの指針となるはずです-あなたの意図は、「発呼者」が、もしあれば、望ましいアクションを成功させるために何ができるかを決定するために必要な情報を提供することです。ファイルへのアクセスエラーのような単純なものである場合は、ファイルパスと、アクセスできなかったというメッセージを指定します。 nullポインタ例外の場合は、一般的なエラーメッセージを表示します。
もちろん、ユーザーが実際に修正できるメッセージよりも「目的のアクションを実行できません」というメッセージが多くなりますが、それは人生です-ほとんどの例外は、ユーザーが環境をセットアップしたためではなく、ミスを犯したためです間違って。
これは一般的なテーマです：
プログラマー、開発者、テスターなどのより高度なユーザーが使用できる情報を示すと同時に、情報のない/コンピューターの読み書きを助けるにはどうすればよいでしょうか。
答えはあなたが両方をすることだと思います！
ただし、順序は重要であり、次のことをお勧めします。
- どうした。
- 今何をする
- 技術的な詳細
技術詳細は、問題を報告する際の事前注文または通常のユーザー向けの情報を持つ部分です
私は受け入れられた答えの背後にある理論的根拠が好きですが、少なくとも情報を"actionable"に限定するという私の解釈には敬意を払わなければなりません。 "unexpected error"よりも、ユーザーとしてそれより少しだけ知りたいです。
確かに私は少しコンピュータに精通していて、その偏見がありますが、これは特に偏った見方ではないと思います。航空のように専門知識がほとんどないドメインにこの考え方を適用することで、そのバイアスを取り除くために最善を尽くすことができるからです。
航空についてはほとんど知りませんが、フライトが遅延またはキャンセルされ、スタッフが私に言ったのは、「予期しないエラーが発生しました。次のフライトまで3時間お待ちください」です。これらのケースでは、少なくとも私を不満に思っている顧客を見つけるでしょう。なぜなら、それがどちらの方法でも私の行動方針に実際には影響しないとしても、私がなぜなのかについて少しだけ知りたいだけだからです。有料の顧客としてこのように不便でした。
彼らが「乱暴な天候が発生している」、「前のフライトで医療緊急事態が発生した」、または機器の故障などのように言っただけで、「予期しないエラー」よりもはるかに同情するのに十分です。座って次のフライトを3時間待って、もう少し内容を確認してください。実際、私は頭の中で「予期しないエラー」のようなテクノバブルを好むかもしれません。たとえば「口から出てきた言葉は私の耳に入りますが、中央処理装置には届きません。しかし、いくつかの種類があるのです。そこに問題があるので、私はコーヒーを手に取り、そこに座って行きます！
また、例外処理に関しては、例外のより技術的な詳細を隠したい場合でも、通常、catchサイトで何が起こったかについての基本的な情報は十分にあると思います。
try
{
load_file(file_name);
}
catch (const exception& ex)
{
exception_dialog("Failed to load file: '{1}'.", file_name);
}
そして、それは例外に付随する非常に技術的な情報である可能性があるものを表示していませんが、少なくとも「予期しないエラー」よりもかなり多くのことを私たちに伝えています。それは、「なぜ/どのように/どのように」と言わなくても、少なくとも「何/どこ/いつ」の文脈を提供します。少なくとも、この基本レベルの情報への欲求は、私のコンピュータの知識に特に偏っていないのではないかと思います。
残りは、おそらく顧客および特定のニーズに非常に固有のものです。しかし、私の魅力は少なくとも「予期しないエラー」よりもほんの少しだけ何かのためのものです。
あなたが見せたいものは、あなたが台無しにしてどれほど恥ずかしいかによって異なります。
ポイントは、障害の詳細を可能な限り迅速かつスムーズにテクニカルサポートに提供することです。つまり、終了エラーのスタックトレースを含むログファイルを自動的にホームに送信するか、転送を開始するボタンをクリックするようユーザーにお願いします。インターネット接続がない場合は、USBスティックを使用している可能性があります。