Eclipse デバッガーで実行すると、ファイルが開かれる FileInputStream.class の 106 行目で常に停止する小さなプロジェクトがあります。ブレークポイントは設定されていませんが、Eclipse は、ここにブレークポイントがあるかのように動作します。すべてのブレークポイントをクリアしても、同じことが起こります。
同じ Eclipse ワークスペース内に、この問題の影響を受けない 2 番目のはるかに大きなプロジェクトがあります。
この問題の発生した Europa Eclipse で開発していた古い Linux マシンから、新しい Windows マシンに小さなプロジェクトを移動したところ、Ganymede Eclipse で引き続き問題が発生しています。この問題はオペレーティング システムや Eclipse のバージョン間で発生していますが、プロジェクト間では発生していないようです。わかりません。このプロジェクトのディレクトリにあるすべてのファイルを grep で検索しましたが、何らかの方法で Eclipse に FileInputStream で停止するように指示しているファイルと思われるものは見つかりませんでした。
さらに詳しい情報: 明らかなブレークポイントは、実際には FileInputStream の 106 行目ではありません。FileInputStream のその行から呼び出されたネイティブ コードからスローされる FileNotFoundException の例外ブレークポイントのようです。しかし、ここでもブレークポイントがまったく設定されていないようです。例外ブレークポイントは他の場所で定義されていますか?
ベストアンサー1
選択を解除しようとしましたか
Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions
？ （としてこのスレッドで言及されている、 例えば）
Eclipse はなぜそのように動作するのでしょうか?
それ2002年に遡るブレークポイント オブジェクト階層が削除された場合。
ブレークポイントを設定するために、古い API では、クライアントは、、などの Java モデル オブジェクトを必要としました。
IType新しいIFieldAPI
では、デバッグ モデルに必要なのは型名、フィールド名などだけです。これにより、Java モデル オブジェクトが利用できない場合でも、クライアントはブレークポイントを設定できます。
クライアントは、ブレークポイントを関連付けるリソースを指定できるようになりました (以前は、関連付けられた Java モデル リソースに制限されていました)。ブレークポイントを「非表示」にすることもできるようになりましたつまり、ブレークポイント マネージャーに登録する必要はありません。
ブレークポイントは選択的に永続化することもできます (マーカーは、マーカー タイプのすべてまたはまったくの永続化のみを許可します)。
これにより、デバッグ モデルがより柔軟になり、クライアントにより多くのビルディング ブロックが提供されます。これにより、Javaデバッグ実装の一部も簡素化されました。たとえば、機能「 」は、特定のプロジェクト内の特定のブレークポイントではなく、
suspend on any uncaught exception「 」という名前のタイプにブレークポイントを設定するだけです。java.lang.ThrowableIType。
ブレークポイントはブレークポイントマネージャに登録されていません（つまり隠れた） - 1つのクライアントのみが認識し、使用しますもう 1 つの例は、
「run to line breakpoint」です。 は、IJavaRunToLineBreakpointその特別な機能が不要になったため削除されました。現在、Java デバッグ UI は、非表示で、永続化されず、ヒット数が 1 の「行ブレークポイント」を作成するだけです。これは、クライアントにビルディング ブロックを提供する例です。