問題タブ [throwable]

Java では、 のまったく新しいサブタイプを作成できますThrowable。たとえば、次のようになります。

さて、ごくまれに、私は次のようなことをするかもしれません:

そしてもちろん他の場所：

私の質問は次のとおりです。

• これは悪い考えですか？もしそうなら、なぜですか？
  • このサブタイピングが悪い考えである場合、それを防ぐために何ができたでしょうか?
  • （私の知る限り）防ぐことはできないため、どのような大惨事が発生する可能性がありますか?
• これがそれほど悪い考えではないのなら、なぜですか?
  • できるという事実から、どうすれば何か役立つものを作ることができるextends Throwableでしょうか?

提案されたシナリオ #1

私が本当にこのようなことをしたいと思ったシナリオには、次の特性があります。

• 「出来事」とは、やがて起こるものです。期待されています。それは間違いなく ではなく、いつ発生するかについては Error何もありません。Exception
  • 期待されているので、catch待ち遠しいです。それは何かを「すり抜ける」ことはありません。catch一般的なExceptionおよび/またはへの試みから「逃げる」ことはありませんError。
• 「イベント」はごくまれに発生します。
• これが発生すると、通常、深いスタック トレースが存在します。

したがって、おそらく、私が言おうとしていることは明らかです。それは、徹底的な再帰的検索FlyingPigの結果です。

捜索対象は存在する：捜索空間である大海原でそれを見つければよい。検索プロセスは時間がかかるため、比較的高価な例外処理のコストは無視できます。実際、フラグを使用する従来の制御フロー構造の代替手段はboolean isFound、再帰のすべてのレベルで、検索プロセス全体で継続的にチェックする必要があるため、よりコストがかかる可能性があります。このチェックは 99.99% の確率で失敗しますが、終了条件を伝播することは絶対に必要です。ある意味では、効果的ですが、チェックは非効率的です!

探しているオブジェクトが見つかったときに単にthrowaを実行するだけで、フラグの管理でコードを混乱させる必要がなくなります。その点でコードがきれいになるだけでなく、この省略により実行速度が向上する可能性があります。FlyingPigboolean isFound

要約すると、次の 2 つのいずれかを選択します。

• 従来の制御フロー アプローチ
  • を使用しboolean isFound、継続的にチェック
  • 99.99% の確率で、小切手は「無駄」です。false
  • 最終的に になるとtrue、再帰を停止し、最初の呼び出しに適切に巻き戻すことができることを確認する必要があります。
• FlyingPigアプローチ
  • 気にしないでくださいboolean isFound。
  • 見つかった場合は、ただthrow new FlyingPig(); それは期待されているので、それには がありますcatch。
  • フラグの管理、boolean続行する必要がある場合の無駄なチェック、再帰を手動で巻き戻す簿記などはありません。

質問:

• (ab)例外を使用するこの手法は有効ですか? （名前はありますか？）
• 有効な場合、必要ですかFlyingPig extends Throwable、それともException問題ありませんか? （その状況に例外は何もないのに？）

現在、既存のコードベース（EJB）をリファクタリングして、ThrowableがEJB内でキャッチされているすべてのブロックを取り除いています。

「Throwableをキャッチする」ことはEJBには使用できないことを適切なドキュメントで周囲の人々に納得させたい/必要があります（これについては多くの議論があります）。Weblogicは、すべての「エラー」状態を処理し、EJBを無効にして、新しい（動作中の）EJBをプールに入れる可能性があります。Throwableをキャッチすると、weblogicが提供するこれらすべてのセキュリティネットが損なわれます。Throwableをキャッチすることは、とにかく悪い習慣です（ただし、ここの人々は消極的で、どこでも「Throwable」ハンマーを使用します）。

この動作が説明されているオンラインドキュメント（weblogic、jbossなど）を誰かに教えてもらえますか？Googleで検索し、weblogicのドキュメントを調べましたが、何も見つかりませんでした。一般的なJavaドキュメントだけです。

java.lang.Error捕まえるべきではないと言っている投稿がたくさんあります。私の質問は、それが何の使用法であるかを理解するべきではないかどうかです。スローアブルなので、トライキャッチでキャッチできます。私はそれが捕らえられるべきであるいくつかの状況でのみ、これらの状況を知る方法のようないくつかの投稿を読みました。

要するに、エラーをキャッチしたときに何がうまくいかないのか知りたいのです。その背後にあるプロセスは何ですか。なぜ彼らはエラーとそのサブクラスを作ったのですか？私のアプリがそれらをキャッチすることになっていない場合、何がそれらをキャッチしますか？なぜ私のコードはこのキャッチされたエラーを処理できないのですか？単に1つのエラーをキャッチし、Catchブロックに処理コードを記述した場合、そのコードは実行されませんか？

これは例外処理に関するばかげたJavaの質問かもしれませんが、ContentProviderのサブクラスからサービスを要求しているUIアクター（Androidアクティビティ）があります。サブクラスは、sd-cardがいっぱいの場合、sd-cardがない場合、ネットワークI / Oエラーなどの場合に、いくつかの例外をスローしたいと考えています。ただし、CPサブクラスをコーディングして例外をスローすると、コンパイラーは例外をに追加することを提案します。 CPクラス。明らかに、基本クラスを変更したくはありませんが、UIでサブクラスの例外をキャッチしたいと思います。

わかる？これは可能ですか？そうでない場合、サービスサブクラスがスロー可能なオブジェクトをUIに戻すためのより良いパターンはありますか？

の違いとthrow、いつどちらを使用するかを説明できる人はいますか?throwsThrowable

Possible duplicate: why-is-java-lang-throwable-a-class

Hi! I doesn't understand why Throwable isn't abstract class. I see only one use case for these: in logging systems for figure out call hierarchy. But it can be some static method for this or other class. So, why?)

Thanks.

upd

from java.util.logging.LogRecord

Why it can't be Throwable.getStackTrace(); or as in java.lang.Thread

In this way we can avoid throw new Throwable();

upd2 from javadoc

The Throwable class is the superclass of all errors and exceptions in the Java language.

So, as a superclass it should be abstract, imho. Using it for getting stacktrace isn't good case by this definition.

私はまだ例外の処理に慣れていないので、例外をスローしているだけですが、このファクトリを使用するメソッドを使用するすべての場所で、throwableのような例外をスローする必要があると言われます。

たとえば、私のクラスの1つに、ファクトリを使用するメソッドを使用して多くのオブジェクトをインスタンス化するメソッドがあります。例外をスローするだけでそのクラスのメソッドを使用できますが、そのクラスへの参照を別のクラスに渡して、そこからメソッドを使用しようとすると機能しません。次に、例外をキャッチしようとします。

工場は必要ないかもしれませんが、面白そうだったので、型紙を使ってみたいと思います。ファクトリを作成した理由は、Pieceのサブクラスが6つあり、メソッドに引数として必要なサブクラスのタイプを渡すことによってそれらをインスタンス化するためにメソッドを使用したくないためです。

ネットワークAPIドキュメントなどのBlackberryドキュメントでThrowableのcatch句をよく目にします。私の感覚では、これは一般的にJavaでは良い習慣ではありません。

ブラックベリープログラミングでこれに理由はありますか？

Throwablesのスタックトレース生成と関係がありますか？

次のテストがあります。

しかし、JUnit は、テストが失敗したことを報告していますが、予想どおりにIllegalStateException.

これを実行するには、何か他の設定を行う必要がありますか?

私は今テストを実行します

この質問のようですが、まだ望ましい結果が得られていません。

testプレフィックスを削除しても、まだエラーが発生します。

これらのテストは Eclipse で実行していると言わざるを得ませんが、Eclipse は JUnit 4 ランナーを使用するように構成されています。

捕まえるのは悪い習慣Throwableですか？

たとえば、次のようなものです。

これは悪い習慣ですか、それともできるだけ具体的にする必要がありますか？