Bug 367017

Summary:	[breakpoints] Investigate expanding type scope for Breakpoint filtering options
Product:	[Eclipse Project] JDT	Reporter:	Ed Willink <ed>
Component:	Debug	Assignee:	JDT-Debug-Inbox <jdt-debug-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	Michael_Rennie, remy.suen
Version:	3.7
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2011-12-17 13:01:39 EST

When trying to set a breakpoint filter on e.g. RebaseCurrentRefCommand which is an EGit class, I am unable to do so, probably because EGit is not on the application class path.

Breakpoint filters should support all types known to the platform in order to allow filtering of any misbehaving tool installed in the platform.

Comment 1 Michael Rennie

2012-02-27 16:30:01 EST

(In reply to comment #0)
> When trying to set a breakpoint filter on e.g. RebaseCurrentRefCommand which is
> an EGit class, I am unable to do so, probably because EGit is not on the
> application class path.

What kind of breakpoint are you trying to set the filter on (I am assuming a Java exception breakpoint, but just confirming)?

Assuming this is an exception breakpoint how are you trying to set the filter(s)? Are you using the 'Add' or 'Add Class' buttons on the property page? If 'Add', you can enter the fully qualified name of any class you want. If 'Add Class' you can only choose from classes that JDT allows in the workspace search scope - i.e. from org.eclipse.jdt.core.search.SearchEngine.createWorkspaceScope().

Comment 2 Ed Willink

2012-02-28 02:25:33 EST

OK. Add and full name would fix it.

But it would be nice if classes on the stack were "Add Class"-able.

And even nicer if a Stack menu option supported "ignore current exception here", which is always what I want; a steadily increasing number of badly behaving support classes throwing inconvenient exceptions.

Comment 3 Michael Rennie

2012-02-29 16:18:14 EST

(In reply to comment #2)
> But it would be nice if classes on the stack were "Add Class"-able.
> 
> And even nicer if a Stack menu option supported "ignore current exception
> here", which is always what I want; a steadily increasing number of badly
> behaving support classes throwing inconvenient exceptions.

I agree, we could improve this. I will change this to an enhancement request and change the name accordingly.