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