問題タブ [unchecked-exception]

BlueJでJavaクラスをコンパイルすると、次のエラーが発生します。

このエラーは、次の逆シリアル化コードが関数の 1 つにある場合にのみ表示されます。

このエラーが表示される理由と、エラーなしで逆シリアル化コードを使用するための助けを教えてください。

次のコードは完全にコンパイルされます。そして、コンパイラは、コンパイル時に、コントロールが finally ブロックに移動し、チェックされていない例外をスローすることを知っているためだと思います (これは問題なく、処理する必要はありません)。この時点までは失われます。心配する必要はありません。

例：

メソッドから未チェックの例外をスローするまでは、これまでのところ問題ありません。

例：

このコードはコンパイルされません。c.m1() をエラー「未処理の例外タイプ _」(eclipse) または「報告されていない例外 _; キャッチするか、スローするように宣言する必要があります」(cmd) でマークします。

finallyブロックが LAST 例外 (チェックされていない) をスローすることを無視したようであり、catch ブロック内の例外が未処理のチェック済み例外であっても心配する必要はありません。とにかく失われるからです! m2() が特に未チェックの例外 (RuntimeException) をスローするように宣言されていることを知っている。

2 番目のコードでコンパイル エラーが発生する理由について、より詳しい説明がある人はいますか? ありがとう ：）

コードを見るだけで、例外クラスがチェックされているかチェックされていないかを判断できますか? 例外を拡張した場合はチェックされるといつも思っていましたが、RuntimeException は Exception を拡張し、それはチェックされていません。RuntimeException は、その経験則を曲げる唯一のクラスである可能性があり、RuntimeException を拡張しない場合、他の未チェックの例外は Throwable を拡張する必要があります。ただし、RuntimeException と Exception の違いがわかりません。違いはインタプリタ自体の中で定義されているのだろうか？

私は Axis を使用して Web サービスに取り組んでおり、そのメソッドが次のように宣言しているチェック済み例外の中で: ServiceException、RemoteExceptionおよびAxisFault(これらはもちろん、呼び出された特定のメソッドに依存するため、これらは関連するすべての例外ではないことはわかっていますが、そうではありませんここがポイント）。

コードでいくつかのテストを行っているときに、うっかり URL に長いポート番号を付けてしまい、コードが (チェックされていない) 例外IllegalArgumentExceptionをスローするようになりました。これは今までキャッチできませんでした。

では、Web サービスやネットワーク全般を操作するときに、処理する必要がある関連するチェックされていない例外はどれですか?
ネットで検索してみましたが、Checked vs unchecked exceptions結果が出続けています。

何かアドバイス？そこにリストまたはガイドはありますか？

たとえば、チェックされていない例外をスローするメソッドがある場合:

メソッドが例外をスローすることを明示的に宣言する利点はありますか、つまり

javadoc で動作を説明するのとは対照的に (またはそれに加えて):

持っていることが役に立たないと私が主張する理由は次のthrowsとおりです。

• throws例外がスローされる状況に関する情報は提供せず、例外がスローされる可能性があることのみを示します。
• これは未チェックの例外であるため、呼び出しコードで例外を処理する必要はありません。doSomething;の実装を見に行くと、それがスローされる可能性があることだけが本当にわかります。
• の本体は、doSomething他のタイプのチェックされていない例外をスローするコードを呼び出す可能性があります。「このメソッドがスローする」と主張することIllegalArgumentExceptionは、潜在的にストーリーの一部を伝えているだけのようです。
• メソッドが非最終的な場合、新しい実装が追加のチェックされていない例外をスローするように宣言されるようにオーバーライドできます。どの実装を呼び出しているかわかりません。

あると便利だと私が主張する理由は次のthrowsとおりです。

• メソッドを呼び出すときに発生することが合理的に予想される問題を報告しています。

throws要するに不要だと思いますが、javadoc の記述 via@throwsがあると便利です。これについて他の人の意見を知りたいです。

ユーザーが動的コンテンツをリポジトリに追加できるようにするサービスがあります。したがって、基本的には、ユーザーが追加するドキュメントのタイプに応じて、その特定のオブジェクトのプロパティのリストを含む汎用 Document クラスがあります (たとえば、請求書ドキュメントには請求書番号プロパティがあり、wiki ドキュメントには作成者プロパティがあるなど)。の上）。

サービスはさまざまなレイヤーで構成されており、ある時点で、追加するドキュメントがルール コンフィギュアラーに準拠しているかどうかを確認し、必要なすべてのプロパティが提供されているかどうか、それらがすべて正しいタイプであるかどうかなどを評価する必要があるクラスがあります。これらの検証のいずれかが失敗した場合、検証ステータスを含むカスタム例外をスローしたいと考えています。

問題は、ValidationException をチェックするか、チェックを外すかです。どのような種類の例外を使用するかを決定する方法について、多くのベスト プラクティスを読みました。私はRuntimeExceptionの使用を考えていましたが、この場合、例外はコーディングのエラーやそのようなものではなく、ユーザー入力によってのみ発生します...一方、チェックされた例外を使用すると、「スロー」構文が伝播することになりますアプリケーションの上記のすべてのレイヤーと、おそらくサービスのメソッドの 90% で、コードの読みやすさと操作性が大幅に低下します。

try...catch ブロックを使用して未チェックの例外を処理することが推奨されないのはなぜですか? 一部の条件付きチェックのみでそれらを回避する必要があるのはなぜですか?

Javaでチェックされていない例外をチェックされた例外に変換できますか? はいの場合、チェックされていない例外をチェックされた例外に変換/ラップする方法を提案してください。