Java例外メッセージの規則はありますか？

Question

私は、それに付随する情報が増えて例外をスローしようとしています。私はそれを冗長にしてデバッグに役立てたいので、複数行にしました。

throw new RuntimeException("Something failed.\n" + 
    "Please provide another dependency on this class\n\n" + 
    " MyClass object = new MyClass(depdencyA, dependencyB)"); 

しかし、私はそれを行う必要がありますか？多くの例外のようなものは1ライナーだと思われますが、私はそれほど冗長ではないと感じています。

私はGradleプラグインを作成していますので、別の表記法があるかどうか教えてください。

1つがある場合は、オラクルのような当局からリファレンスまたはドキュメントを表示してください。

Answer 1

例外（および例外メッセージ）は、可能な限り具体的かつ簡潔でなければなりません。

問題を特定し、問題の解決方法をユーザー（または管理者）に知らせるために十分な情報を提供する必要があります。

あなたの例では、これらの点で失敗：

1. RuntimeExceptionは非常に一般的である - より具体的な例外型（おそらくいくつかの既存の例外タイプ、作成したかもしれないいくつかの例外タイプ）
2. を選択し、「何かに失敗しました。」すべてがOKだった場合は例外をスローしません
3. "このクラスに別の依存関係を提供してください" - クラスに特定の数の依存関係が必要な場合は、 "5つの依存関係のうち2つだけが提供されました" 。 "No DataSource found"
4. "MyClassオブジェクト=新しいMyClass（depdencyA、dependencyB）" - この部分は、ユーザー側でいくつかの呼び出しスタイルを想定しています。あなたのコンストラクタ/メソッドが、リフレクションまたはメソッド参照を使用して呼び出された場合はどうなりますか？例外がスローされた正確な場所はまたスタックトレース内に含まれている
5. - もう一度あなたの例外メッセージに

Answer 2

一般的な規則はありません。しかし：そのようなRuntimeExceptionを投げる

1. は一般的に悪い考えです。

2. 冗長な例外メッセージは、通常のユーザーを対象にしている場合、圧倒的な可能性があります。

3. 例外メッセージに埋め込まれたマークアップ（改行、タブなど）が賢明に処理されるという保証はありません。 （スタートのために、次のメッセージが表示され、固定幅フォント（さえ）が使用されるかどうかをそのウィンドウの文字幅を予測することはできません。）

4. 国際化を....

Gradleの場合は、他のプラグインの動作を確認したり、Gradleが複数行の例外メッセージをどのように処理するかを確認する必要があります。

---

診断のための余分な詳細を提供するに対処するための別の方法は、あなたが例外をスロー前に...詳細をINFOまたはDEBUGイベントをログに記録するアプリケーションのロガーを使用することです。