14

InterruptedExceptionGuavaでThrowables.propagate(e)を使用するときにsを処理するためのベストプラクティスは何ですか?

throw Throwables.propagate(e)私は、特にチェック例外をスローしないメソッドや、例外処理が呼び出し元の責任であるメソッドでを使用するのが大好きです。しかし、InterruptedException で期待することはできません。

スレッドが中断されたという事実を失いたくないので、次のように記述します。

public void run() {
    Callable c = ...;
    try {
        c.call();
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw Throwables.propagate(e);
    } catch (Exception e) {
        throw Throwables.propagate(e);
    }
}

Guavaでこれを行う方法はありますか? スレッドが InterruptedException をラップして伝播している場合、スレッドを中断済みとして設定する Throwables.propagate() のようなものを使用する (下位互換性がある?!) 方法はありますか?

4

1 に答える 1

8

都合のよいことに、これについては社内で少し前に話し合った。コピーして貼り付けるだけです：

についての私の強硬な意見Throwables.propagate(e)は、それは基本的throw new RuntimeException(e)であり、通常は書くべきではないのと同じように、人々は通常それを行うべきではないということthrow new RuntimeException(e)です。(そして、彼らがそれを書くつもりなら、何が起こっているのかが明確になるように直接書いたほうがよいでしょう。)

通常、人々がこの混乱に陥る方法についての私の強硬な意見catch (Exception e)は、通常はそうすべきではないということです。（明らかに、catch (Exception e)明らかに正しいことを行う場合があります（基本的には、トップレベルの操作スコープのキャッチブロック）が、それらは...明らかです。）

私の強硬な意見InterruptedExceptionは、まったくInterruptedException実装Exceptionすることは、まさにこのように壊れているということです。他の例外では必要のない特別な処理が必要です。

InterruptedExceptionへの変換に関する私の強硬な意見RuntimeExceptionは、「しない」です。（これは、私が上で述べた他の多くのことと同様に、物議を醸しています。）

そのため、一方では、救助するために私たちにできることがあるかどうかはわかりませんpropagate(). 一方で、メソッドを少し悪くするのはいいことかもしれません。

次に、キャッチするこの呼び出し元を考えてみましょうExecutionException e:

throw Throwables.propagate(e.getCause());

e.getCause()割り込みはコンシューマー スレッドではなくコンピューティング スレッドを対象としているため、直接スローするのが間違っているのと同様に、コンシューマー スレッドに割り込むのも間違っています。

私はpropagate()一人で去る傾向があります。(おそらくご想像のとおり、私は個人的にそれを非推奨にする傾向がありますが、それはより大きな議論です。)

于 2012-10-10T16:58:12.633 に答える