2012-04-25 7 views
0

私はエラーを完全に処理するJava RuntimeErrorのkludgeyを使用しています。問題は、私が派生し投げたランタイムエラーがどこで発生したのか、私に迷惑な痕跡を与えることです。このトレースを抑制する方法は?Java - カスタムランタイムエラーがダンプトレースを生成しない

参考のために、問題は非投げのクラスをサブクラス化し、スローするために私のサブクラスを必要としたことです。 「Cプログラムのように読めるようにプログラムを書き換える」か「実行時エラーを使用してスロー指定の要件をバイパスする」のいずれかでした。明らかに、私はスロー・スペックの要件が非常に逆効果的であることを発見しています。「workIsDone」変数の束を維持することを含まない他の回避策は高く評価されます。コードなし

+1

何ですか?コードをご覧ください。 – sjr

+0

エラーを完全に処理するのは何ですか? – Gren

+0

Java RuntimeErrorとは何ですか? RuntimeErrorというクラスがありますか?どのパッケージからですか? – JeanValjean

答えて

1

それはあなたが何を言ってるのか知ることはとても難しいのですが、一般的には、スタックトレースは、例外をキャッチハンドラから来、その上にprintStackTrace()を呼び出します。スタックトレースは何か要求がない限り表示されません。今、例外がAWTイベントスレッドスタックの最上位に向かう場合、デフォルトのハンドラはこのように出力します。

通常、例外を処理する必要があります。実行時例外を使用して、一部のスーパークラスメソッドで例外が宣言されていないことを知ることはできますが、その例外を常にキャッチする責任があります。できない場合(他のコードが代わりにそのコードをキャッチする場合)、これは悪い戦略であり、使用できません。

+0

printStackTraceのオーバーライド/抑制はここで行うことでした。私はこの答えを8m inutesで受け入れることができます。 – djechlin

+0

だから、おそらく... upvote? –

+0

@djechlin 'printStackTrace()'はデフォルトで呼び出されません!実行時にExceptionをキャッチした場合、エラーを出力するかどうかを決定する必要があります。もちろん、例外はあなたのアプリケーションやそれがスローされたスレッドを破壊する可能性があります。 – JeanValjean

関連する問題