0

私の GWT クライアントではThrowable、実装に渡されたCallback#onFailure()が常に処理されるようにしようとしています。これは、この膨大なコード ベースの多くの実装がそれについて何もしていないためです。

これを行うために、独自の実装でRemoteServiceProxy#doCreateRequestCallback()すべてをラップする独自の定義をしました。Callbackその#onFailure()メソッドでは、独自のバージョンの a を使用して、Throwable処理されるかどうかを追跡できるようにしたいと考えています。whenThrowable#getMessage()が呼び出されるので、元の に渡しCallback#onFailure()ます。

public class ThrowableProxy extends Throwable {
    private Throwable delegate;
    private boolean handled;

    public ThrowableProxy(Throwable delegate) {
        this.delegate = delegate;
        this.handled = false;
    }

    // Overriding Throwable's methods to defer to the delegate

    // package protected
    boolean isHandled() {
        return this.handled;
    }
}

instanceofをヒットするまで、これはすべて問題ないように見えます。ここで、クライアントコードが例外のタイプをチェックしたい場合、たとえば. throwable instanceof StatusCodeException、Throwable は のインスタンスですがThrowableProxy、本当に必要なのはデリゲートの型を確認することです。

instanceofはどのように機能しますか? のようなことをせずにデリゲートをチェックさせることはできますthrowable.getDelegate() instanceof StatusCodeExceptionか?

4

2 に答える 2

0

ここで何を達成しようとしているのかよくわかりません。ここで何を達成しようとしているのかを詳しく説明していただけると非常に助かります。しかし、これはあなたが提供した情報に基づいて私が見るものです...

クライアントでさまざまな例外に対して instanceof をチェックしようとしている場合、すべての例外がクライアントで使用できるわけではないため、最終的にレンガの壁にぶつかります。クライアントはコンパイル時に Javascript を実行し、考慮すべき制限があることに注意してください。例外の限定セットが含まれます。クライアントで一元化されたエラー処理を実装する良い方法は、次を使用することです。

GWT.setUncaughtExceptionHandler

これにより、アプリで明示的に処理されていないすべての例外を最終的にキャッチするUncaughtExceptionHandlerを実装できます。これを行う良い方法は、独自のアプリ固有のランタイム例外を実装することです。これにより、明らかに必要なきめ細かな処理が可能になります。

正直なところ、あなたの目標が何であるかがわからないので、これは大げさな推測です。

于 2013-07-23T22:20:08.170 に答える
0

instanceof は通常の Java と同じように機能します。ThrowableProxy に対して「オーバーライド」することはできません。

何を達成したいのか完全にはわかりませんが、すべてのコールバックで独自のクラスを拡張し、handledFailure(ex) メソッドを呼び出す必要があり、onFailure が呼び出されずに返された場合に何かを行うことができます。もちろん、その呼び出しを行うようにコードを変更している場合は、実際にエラーを処理するようにコードを簡単に変更できます。

ところで、instanceof を使用して型のランドリー リストをチェックするのはコードの匂いであり、チェックしているものをエンコードするには、おそらく共通のスーパークラスが必要であることを示しています。

于 2013-07-23T15:16:50.027 に答える