c# - 例外メッセージにはどのようなスタイルを使用していますか?

Question

ここで質問した例外をスローするコードを書いているときに、メッセージの最後に来て、句読点で一時停止しました。これまでにスローしたほぼすべての例外メッセージには、おそらく ! が含まれていることに気付きました。どこか。

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

例外メッセージを書くとき、あなたはどのようなトーンをとりますか? ログを調べたときに、特定のスタイルのメッセージが実際に他よりも役立つことがわかりましたか?

score 6 · Accepted Answer

システムメッセージの会話調は、ソフトウェアを専門的ではなくずさんに見せます。感嘆符、侮辱、スラングは、洗練された例外メッセージには実際には存在しません。

また、ランタイム例外は間違いを犯したプログラマーに向けられるため、Java ではランタイム例外とチェック済み例外に異なるスタイルを使用する傾向があります。実行時例外はエンドユーザーに表示される可能性があるため、「クリーンな状態に保ちます」が、もう少し簡潔で不可解なものになる可能性があります。チェックされた例外メッセージは、説明すればユーザーが問題を解決できる可能性があるため、より役立つはずです (たとえば、ファイルが見つからない、ディスクがいっぱい、ホストへのルートがないなど)。

情報の例外に特定のフィールドがない場合に役立つことの 1 つは、問題のあるデータです。

throw new IndexOutOfBoundsException("offset < 0: " + off);

score 6 · Accepted Answer

当たり前のことです。デバッグ時に必要になる可能性が高いすべての情報を含めますが、それ以上は含めないでください。

私が例外メッセージに感嘆符を含めるのは、本当に奇妙なことが起こったことを示す場合だけです。ほとんどのエラーは実際には奇妙なものではなく、不適切な環境、ユーザーエラー、または単純なプログラミングミスの産物です。

score 6 · Accepted Answer

コーディング対象のフレームワークのトーン、文法、句読点のスタイルを反映するようにしています。これらのメッセージの 1 つが実際にクライアントやユーザーの前にいつ届くかはわかりません。そのため、私はすべてをトラブルシューティングに十分な専門的で判断力のない具体的なものにしています。コード。

単体テストを除いて、疫病のようにすべての文字列 (UI と例外) で感嘆符を避けます。

score 3 · Accepted Answer

実際にユーザーの責任であったとしても、責任を取ることは、私が見た中で最良の選択肢です。

「お探しのファイルが見つかりません。ファイルが正しくあることを確認していただけますか?」または「何か問題が発生しました。何が原因かわかりませんが、修正するには停止するしかありません。再起動してください。」

score 2 · Accepted Answer

簡潔で詳細な冗長情報はほとんどありません (つまり、ArgumentNullException には明らかに null が含まれていました)。

しかし、これは私がしばらく読んだ中で最高のものです。これに対する最初の答えです。

score 2 · Accepted Answer

感嘆符はあまり使いません。彼らはあまりにも多くのことを表現し、「ドライブにディスクがありません!」という事実について考えてみてください。「狂ったユーザーのドライブにディスクがありません」と読むことができます。;)

国際化されたテキストを含む例外をスローするのが賢明だと思います。誰があなたのコードを使用し、例外をキャッチし、テキストをユーザーに表示するかはわかりません。つまり、次のようになります。

throw new MagicalException(getText("magical.exception.text"));

また、スローするときに、基になる例外 (ある場合) をラップすることをお勧めします。デバッグに本当に役立ちます。

実行時例外がユーザーに表示されないとは思わないでください。ファイルアペンダーにログインしている場合、好奇心旺盛なユーザーがログを開いて、ダーティシークレットをのぞき見する可能性があります。

score 2 · Accepted Answer

最も役立つメッセージは次のとおりです。

彼らがあなたに言っていることを理解しやすくする一貫したフォーマット。
タイムスタンプ。プログラムのダイナミクスを把握できます。
エラーの簡潔な要約。技術サポートを提供する場合は、迅速に識別できるようにエラーコードを追加してください。
無効なユーザー入力とコーディングエラーを区別する、問題の原因の説明。
関連するコード行や値などの詳細情報。

そして最も重要なこと：

問題を解決する方法をユーザーに伝えます。

例：

commit.c 行 42 のエラー 203 (タイムアウト):
ユーザー「Linus」の給与データを「10.10.1.21」のデータベースに保存できません
1500ms後。データベース アドレスとログイン資格情報を確認します。

学ぶのが最も難しい教訓の 1 つは、ユーザーは自分の仕事を成し遂げることよりも、コードの内部にあまり関心がないということです。 彼らが仕事をできる限り簡単に行えるようにすると、ソフトウェアに多大な価値が追加されます。

score 1 · Accepted Answer

礼儀正しく、簡潔で、シンプルで、具体的です。多くの場合、メッセージに状態値を含めると便利です。

score 1 · Accepted Answer

私は例外メッセージを例外自体に組み込む傾向があります。たとえば、file_not_found は「ファイルが見つかりません」と表示されます。特定のデータは、ユーザーが理解できない場合にのみ含める必要があります。この場合、ユーザーはファイル名を知っているので、そのデータは追加しません。フォーマットは、必要に応じて情報を出力することで行うことができるので、できるだけ再フォーマットしやすいようにしています。

c# - 例外メッセージにはどのようなスタイルを使用していますか?

9 に答える 9

Related

Reference