This is because .NET code in general reserves throwing exceptions for exceptional cases. This functionality allows me to catch a NUMBER of issues in code quality, and I

very much miss this in Java !

Unfortunately, java developers are not as lucky as .NET, because some java functionality (classloaders being notorius!) uses exceptions for fairly
unexceptional things.

I would like the following behaviour:
"ignore this exception when thrown at this location"
"ignore this exception when thrown at this location AND the condition is satisfied at this location"
"ignore this exception when thrown at this location AND a specific class/method is on the call-stack" (advanced)
"trigger on throws" for ALL other exceptions.

Initially, I will try to see how this could fit into the current UI. Later in this issue, I will argument that the whole breakpoint ui should be reworked:

It seems like a lot of what I am looking for could have been provided with Conditions and Exception breakpoints, but
I do not think its possible because the "ignore" notification is missing, or the trigger options are not good enough.

It also seems to me like the "notifications" for exception breakpoints use a "kind of weird" semantic, at least when compared to visual studio. Visual studio provides

"trigger on throw" and "trigger on throw if unhandled" - meaning that there is no-one catching this exception on the callstack. Idea seems to provide "trigger on catch"

and "trigger on method that is not catching" (or maybe the documentation is just not too clear on this last one).

But I still think the whole exception gui should be reqorked and simplified, probably hiding most of the existing gui in an "advanced" tab or something:
I think this should be the primary scenario for exception breakpoints. In visual studio it is possible to "debug with pleasure"
because nobody throws exceptions for regular logic. In java we need additional functionality to specify which exceptions should be ignored because a lot of stuff uses

exceptions badly, we need to easily evaluate conditions surrounding the breakpoints at the throwing location.

When I say that think this is the "primary scenario" for exception breakpoints I also think that the current UI for this feature tries to make exception breakpoints
"the same" as line-based breakpoints. They are not, and I think you are missing the most important aspects of exception breakpoints.

As an additional note, I have also attached some thoughts that may be relevant:
I quite often use the class filters to exclude some of the standard offenders, but unfortunately I use maven (which forward generates idea projects and I lose all the

debugger settings!), and there are others I am working together with and I would essentially like to have a project shared set of class excludes.

I would like the annotation:

• @DebuggerDoNotStopOnException(java.lang.ClassNotFoundException) (or idea-specific annotation)
  Essentially allows the debugger to ignore a specified exception even if it matches an exception breakpoint. Global setting should be able to ignore this annotation. Should

apply for this method and any invoked methods.

• An easy way to add a filter for the current class/method when the debugger has stopped somewhere and I am quite sure it doesnt matter.

I am fairy sure a smart lot like you guys could extend/improve my list, and any suggestions on how I can attain this functionality would be welcome !