問題タブ [checked-exceptions]

私は次のコードを持っています：

メソッド宣言で宣言されているが、行でキャッチされていないキャッチされていないランタイム例外で警告/エラーを表示できるEclipseの構成はありますwillItThrowException();か？

xsd に対して xml を検証していますが、例外を処理する必要がある場合が多いことがわかりました。

これらはJavaでチェック例外と呼ばれていると思いますか?

このコード ブロックはどのように記述すればよいですか?

try/catch 内にネストされた try/catch を使用しますか?

guavaCacheを使用するようにいくつかのコードをリファクタリングしています。

初期コード：

何かを壊さないために、スローされた例外をラップせずにそのまま保持する必要があります。

現在の解決策はやや醜いようです：

それをより良くするための可能な方法はありますか？

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

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

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

私はこのような方法を持っています:

Exceptionインサイドを投げたいgetSomething()。Exception私のメソッドがそこにスローされることを許可していないため、コンパイラはそれを許可しません。Exceptionしかし、テスト用にのサブクラスをスローする必要があります( Unchecked をスローすることはできませんException)。これは明らかにハックですが、テストには必要です。EasyMock を試しましたが、それもできません。それを行う方法はありますか？

ありがとう、ショーン・グエン

私は最近、javac コンパイラーを介してチェック済み例外をこっそりとスローして、スローしてはならない場所にスローすることが可能であるという事実を発見し、ブログに書きました。これは Java 6 および 7 でコンパイルおよび実行され、with or 句がスローさSQLExceptionれthrowsますcatch。

生成されたバイトコードは、JVM がチェック済み/未チェックの例外をあまり気にしていないことを示しています。

これを受け入れるJVMは1つのことです。しかし、Java-the-languageがそうあるべきかどうか、私には疑問があります。JLS のどの部分がこの動作を正当化しますか? バグですか？それとも、Java 言語の隠れた「機能」ですか?

私の気持ちは次のとおりです。

• doThrow0()はin に<E>バインドされています。したがって、JLS §11.2の行に沿った節は では必要ありません。RuntimeExceptiondoThrow()throwsdoThrow()
• RuntimeExceptionは との代入互換性があるため、コンパイラによってExceptionキャスト (結果として) が生成されません。ClassCastException

これについてできることはすべて読みましたが、チェック済み例外とチェックなし例外の使用方法をまだ理解していません。まだまだコンセプトが理解できていないと思います。チェックされた例外ではなくチェックされていない例外を使用する方が良いことを StackOverflow で読みましたが、Eclipse では、次のようにチェックされた例外を使用するように強制FileNotFoundExceptionされます(私の知る限り、Eclipse が try/catch ブロックを挿入するように強制する場合、それはチェックされた例外です)。チェックされているものをチェックされていないものに変換する方法はありますか？一体何を扱っているのですか？例外を処理するとはどういうことかわかりません。

ここにこの例があります。これを処理する方法 (?) を本当に知りたいです。これはチェック例外ですよね？

私は人々がここでしていることをいろいろ見てきました。スタックトレースを出力する人もいますが、それは私が通常行っていることであり、問​​題はありません。デバッグに必要な情報が得られます。それらを無視する人もいますが、それはすべきではないと思います (JNode OS ブーターが例外を無視しているのを見ました)。throws一部の人々は、署名に宣言を追加するだけです。その中にさらに例外をスローする人もいます! (多分これは、チェックされた手段の代わりにチェックされていないものを使用することだと思いますか?)

さらに、throws宣言を追加すると、try/catch ブロックをさらに上に置く必要があり、非常に大きなアプリケーションの場合は不便です。申し訳ありませんが、私は単に無知です。完全に。私は優れたエレガントなデザインを学ぼうとしていますが、これは私を苦しめています.

私はC＃の入門書を読みましたが、それをどうするかわからない場合は例外をキャッチするべきではありません。Javaでプログラミングしているときにそのアドバイスを考えると、例外をどうすればよいかわからないことがありますが、コンパイルエラーを回避するために、それをキャッチするか「浸透」させる必要があります。throws呼び出しツリーのずっと上まで句を含むメソッドを乱雑にしたくないのでRuntimeException、次のように例外をaに「変換」することにしばしば頼りました。実際には「処理」されていない（適切に処理されていない）例外の多くのメソッドに句を追加するthrowsと、冗長で気が散るように見えます。次の悪いスタイルですか？もしそうなら、これに対処するためのより良い方法は何ですか？

編集：混乱は別として、パーコレーション例外には別の問題があります。コードの改訂後、おそらくいくつかの不要なthrows句が発生することになります。それらをクリーンアップするために私が知っている唯一の方法は、試行錯誤によるものです。それらを削除して、コンパイラーが文句を言うかどうかを確認します。明らかに、コードをクリーンに保ちたい場合、これは厄介です。

私はJavaが初めてで、プログラミングも初めてです（Javaに直接飛び込むのはおそらく最高のアイデアではなかったことを知っています）。プログラムに一時停止を追加しようとしても、一貫してエラーが発生します。私は単純なカウント プログラムを実行しており、各数値の間に 1 秒の遅延を追加したいと考えています。これまでのコードは次のとおりです。

への呼び出しThread.sleep()はコンパイルされません。コンパイラは、「報告されていjavacない例外 InterruptedException; スローされるようにキャッチまたは宣言する必要があります」と言い、Eclipse は「ハンドルされていない例外タイプ InterruptedException」と言います。

私は Java 8 の新しいラムダ機能をいじっていて、Java 8 が提供するプラクティスが本当に役立つことを発見しました。ただし、次のシナリオを回避する良い方法があるのではないかと考えています。たとえば、オブジェクト プールを埋めるためにある種のファクトリを必要とするオブジェクト プール ラッパーがあるとします ( を使用java.lang.functions.Factory):

関数型インターフェースをラムダ式に変換すると、上記のコードは次のようになります。

確かにそれほど悪くはありませんが、チェックされた例外にはラムダ内に/ブロックjava.sql.SQLExceptionが必要です。私の会社では、長い間 2 つのインターフェイスを使用しています。trycatch

• IOut<T>java.lang.functions.Factoryこれは;と同等です。
• 通常はチェック例外の伝播が必要な場合のための特別なインターフェース: interface IUnsafeOut<T, E extends Throwable> { T out() throws E; }.

IOut<T>Java 8 への移行中にとの両方IUnsafeOut<T>が削除されるはずですが、 と完全に一致するものはありませんIUnsafeOut<T, E>。ラムダ式がチェックされた例外をチェックされていないかのように処理できる場合、上記のコンストラクターで次のように単純に使用できる可能性があります。

それはずっときれいに見えます。ObjectPoolスーパークラスを書き直してIUnsafeOut<T>私たちの

• に似たものを実装しIUnsafeOut<T, E>ますか？（正直なところ、私はそれを汚いと考えています-サブジェクトは何を受け入れるかを選択する必要があります：どちらか、Factoryまたは互換性のあるメソッドシグネチャを持つことができない「安全でないファクトリ」）
• ラムダでチェック例外を無視するだけなので、IUnsafeOut<T, E>サロゲートは必要ありませんか? （なぜですか？たとえば、別の重要な変更：私が使用しているOpenJDKは、匿名クラス[関数インターフェイス]またはラムダ式でキャプチャされるjavacように変数とパラメーターを宣言する必要がなくなりました）final

したがって、問題は一般的に次のとおりです。ラムダでチェック済み例外をバイパスする方法はありますか、またはJava 8が最終的にリリースされるまで、将来的に計画されていますか?

更新 1

うーん、私たちが現在持っているものを理解している限り、参照されている記事は 2010 年のものですが、現時点では方法がないようです: Brian Goetz は Java で例外の透過性を説明しています。Java 8 で何も変わっていない場合、これは答えと見なすことができます。また、Brian は、interface ExceptionalCallable<V, E extends Exception>(私が言及しIUnsafeOut<T, E extends Throwable>たコードの遺産から外れたもの) はほとんど役に立たないと言い、私も彼に同意します。

私はまだ何か他のものを見逃していますか？