2

run()メソッドでいくつかのストリームを処理する抽象スレッドを作成しました。抽象親クラスではなく、サブクラスにこれらの例外を処理させたいのですが、それを行うための最も洗練された方法がわかりません。今、私はこのようなことをしています:

import org.apache.logging.log4j; // (I use log4j for logging)

public interface Loggable {
     Logger getLogger();
}

public abstract class ParentThread extends Thread implements Loggable {
    private final static Logger logger =
      Logger.getLogger(ParentThread.class); // Logger with no Appenders

    @Override
    public void run() {
        try {
            // Do some stuff that throws exceptions
            doAbstractStuff();
        } catch (SomeSortOfException ex) {
            getLogger().error("Oh noes!", ex);
        } catch (SomeOtherException ex) {
            getLogger().error("The sky is falling!", ex);
        }
    }

    public Logger getLogger() { return logger; }

    protected abstract void doAbstractStuff();
}

public class ChildThread extends ParentThread {

    @Override
    public Logger getLogger() { /* return a logger that I actually use */ }

    @Override
    public void doAbstractStuff() { /* Implementation */ }
}

ChildThreadは実際には私のメインフォームの内部クラスであり、そのロガーはそのフォームに属していることを言及する必要があると思います。

私が考えた別のアプローチは、

abstract void handleException(Exception ex);

ParentThreadにありますが、ChildThreadからの個々の例外を処理できません。

4

3 に答える 3

0

まあ、間に違いはありません

} catch (SomeSortOfException ex) {
    getLogger().error("Oh noes!", ex);
} catch (SomeOtherException ex) {
    getLogger().error("The sky is falling!", ex);
}

if (ex instanceof SomeSortOfException) {
    getLogger().error("Oh noes!", ex);
} else if (ex instanceof SomeOtherException) {
    getLogger().error("The sky is falling!", ex);
}

後者はある程度の鋳造が必要かもしれませんが。

あなたのabstract handleException(Exception ex)考えは健全です、私はそれで行きます。しかし、私はそれを作らないabstract傾向があり、賢明なデフォルトの実装をで定義し、必要に応じてそれをオーバーライドParentThreadできるようにします。ChildThread

于 2011-04-23T09:43:05.140 に答える
0

基本クラスが例外をログに記録するのはなぜですか? プラットフォームが提供する Thread.setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh) を使用して、ロギングと do-stuff コンポーネントを混在させる代わりに、プラットフォームに何でもさせてみませんか。

于 2011-04-23T11:17:31.613 に答える
0

あなたの最初の解決策は、私には概念的に間違っているようです:アプリケーション固有のエラー処理と一般的なログを混在させます。

2 番目のアイデア (コールバック) はより良い解決策のようで、カスタム イベントの実装固有の例外を抽象化する可能性を提供します。次に例を示します。

public abstract class Parent {

    public void run() {

        InputStream in = null;    
        try {
            in = new URL("bladiebla").openConnection().getInputStream();    
            String text = // ...read text from InputStream     
            if (text == null || text.length() == 0) {
                handleMyEvent(new NoInputEvent());
                return;
            }           
            doWork(text);
        } catch (MalformedURLException e) {
            handleMyEvent(new MyEvent(e));                
        } catch (IOException e) {
            handleMyEvent(new MyEvent(e));
        }
        finally {
            if (in != null) {
                try {
                    in.close();
                }
                catch(IOException e) {
                    handleMyEvent(e);
                }
            }
        }
    }            

    abstract void doWork(String text);

    abstract void handleMyEvent(MyEvent myEvent);
}

public class MyEvent {
    private Exception exception;
    public MyEvent() {}
    public MyEvent(Exception exception) {//set it}
}

public class NoInputEvent extends MyEvent {        
}
于 2011-04-23T11:05:11.173 に答える