問題タブ [throws]

@throwsアプリケーションが複数の理由で同じ例外をスローする場合、複数の javadoc タグを使用できますか? 例えば：

JavaDoc標準で禁止されていますか?

OSGIBundleActivatorstartのメソッドとstopメソッドの両方が。で宣言されています。同時に、彼の著書「Effective Java、Second Edition、Item 62」の中で、JoshuaBlochは次のように述べています。throws Exception

メソッドが「例外をスローする」と宣言しないでください

それでBundleActivator、この場合、それは不十分な設計決定であるか、またはそのような一般性が正当化されるのでしょうか、そしてなぜですか？

そもそも例外をスローするのではなく、例外をキャッチして再スローすることの利点について、私は混乱しています。

例えば

対：

これは、エラー メッセージのスタック トレースを保持するためですか? 例を設定しようとしましたが、2 つの間で異なる出力は見られませんでした。

助けてくれてありがとう。

次のようなインターフェイスを定義したい

実装時に、selfDefinedException は異なります。(今のところ一般的な undefined としての selfDefinedException) これを行う方法はありますか?

ありがとう

例外のあるインターフェイスは、例外なしでインターフェイスを拡張します

ヘイ、

ユーザー名として機能する一意のフィールド email を持つ User-Table があります。同じ情報で dao.create メソッドを 2 回呼び出すと、org.springframework.dao.DataIntegrityViolationException (Duplicate entry....) が発生します。これにより、userDao.create(o) でチェック済み例外をスローする必要があるポイントに到達します。今、私は UserDao-Interface が GenericDao-Interface を拡張するという問題を抱えています。これは、throw-clause なしで create メソッドを既に定義しています。

拡張するインターフェイスは、拡張しているインターフェイスよりも多くの例外をスローできないため、このコードはコンパイルされません。

(これが原因である理由については、Java インターフェイスが質問を拡張する(cletus からの回答) を参照してください)

今私の質問: この問題を解決するためのベスト プラクティスは何ですか?

事前にご回答いただきありがとうございます=）

PS: これまでのところ、私はいくつかの答えを思いつきましたが、それらは私を本当に満足させるものではありません. 1 つには、GenericDao にチェック例外をスローさせることができますが、テーブルの約 99% には (pk 以外の) 一意のフィールドがないため、これは受け入れられません。UserExistsException を Runtime-Exception にして文書化するのは、メソッドのユーザーに強制的に例外をキャッチさせてエンドユーザーに報告させたいため、あまりうまくいきません。Exeption をスローする新しい userDao.createUser() メソッドを作成し、既存の userDao.create() メソッドで UnsupportedOperationException をスローすることは、これまでに頭に浮かんだすべてのソリューションの中で最も整然としたものであることがわかりました。私はまだ知りたいのですが、この問題を解決する適切な方法は何ですか?

Runnableを実装するクラスのrun（）で呼び出しているメソッドは、例外をスローするように設計されています。

しかし、Javaコンパイラーはそれを許可せず、try/catchで囲むことを提案します。

問題は、それをtry / catchで囲むことにより、その特定 のrun（）を役に立たなくすることです。その例外をスローしたいのですが。

run（）自体を指定するthrowsと、コンパイラはそれを文句を言います。Exception is not compatible with throws clause in Runnable.run()

通常、 run（）に例外をスローさせなくても問題ありません。しかし、私にはその機能が必要な独特の状況があります。

この制限を回避するにはどうすればよいですか？

コンパイラがそのメソッドshow2()を報告する理由、、、show3()およびmain()

報告されていない例外キャッチするか、スローするように宣言する必要がある例外

throws Exceptionこれらのメソッドから削除するとどうなりますか？

メソッドが例外をスローする場合、メソッド内に try ブロックが必要ですか?

例えば、

try ブロックは必要ですか? または、それなしで SomeException をスローできるメソッドですか?

これは、 throwで SomeException を明示的にスローしていない場合です。

通常、Java コンパイラは、スローされるすべてのチェック例外がスロー仕様に含まれていることを確認します。ネイティブ関数が、関数のスロー仕様リストにない Java チェック済み例外をスローすると、何か特別なことが起こりますか? または、実行時にスロー仕様リストが単純に無視されますか?

C++

ジャワ

(C++ 関数名はおそらくマングルされます。また、loadLibrary は try キャッチに含まれている必要があります。気にしないでください。問題に関連しているとは思いません。コードに他のエラーがある可能性がありますが、おそらく関連性はありませんまた。）