2

私のプロジェクトでは、以下のように LoadableDetachableModel を使用しています。

public ReportPage(final Objectm, final PageReference pr) throws CustomException{
try{
final LoadableDetachableModel<List<MaintReport>> ldm = 
         new LoadableDetachableModel<List<MaintReport>>() {

            @Override
            protected List<MaintReport>load() {
                **// Some Database operations //** 
                return x;
            }
        };

/*
Several LoadableDetachableModels, PageableListViews, Panels, Fragments  etc.
*/ 
} catch ( Exception ex){
// create Custom Exception 
} finally {
 // Clean up of stuff 
}

問題は、オーバーライド関数load()が何らかのデータベース操作を伴うことです。このメソッドから例外がスローされた場合、またはこのメソッドから例外が発生した場合、どこでキャッチできますか? . 釣れないらしい。ログ メッセージを書き込んでみると、load()コンストラクター全体が実行された後にメソッドが呼び出されていることがわかります。データベース操作をメソッド
の外に確実に移動できます。load()しかし、そうする方法はありますか？

どなたか経験された方がいらっしゃいましたら、情報共有いただけると助かります。

4

2 に答える 2

3

このコードはメソッドを定義するだけでload()メソッドを呼び出していないため、スローされた例外はこの try-catch でキャッチされません。

のload()メソッドLoadableDetachableModelは通常、 でgetObject()定義されているメソッドのみがLoadableDetachableModel呼び出され、アプリケーションや Wicket フレームワーク自体の他の場所から呼び出されます。

load()データベースアクセスで発生する可能性のある例外を処理するために、おそらくメソッド自体の内部に try-catchが必要です。そのメソッド内で処理できない例外がある場合は、例外をWicketRuntimeExceptionラップしてスローできます。これにより、通常はエラー ページが表示されます。

そのメソッドの外でデータベースエラーを処理するのは面倒です。他の回答へのコメントは、どのように進めるかについてのヒントを与えてくれます。

于 2013-02-18T16:30:28.493 に答える
3

それは例外処理の仕組みではありません。LDM 内で例外処理を行う必要があります。一部のデータベース操作を try-catch ステートメントでラップします。

于 2013-02-18T16:05:34.313 に答える