From a discussion about this topic:
In the 3.4 debugger, there is not any good indication about when line
breakpoints are or are not live (that is, one can set a line
breakpoint, but it will never be hit because there is no debugging
information associated with the method).

BREAKPOINT APPEARANCE
Provide feedback in the icons for breakpoints when they aren't valid.
a) No breakpoints are valid when there are no debugging sessions
b) A breakpoint is not valid if there are no sessions that understand
that kind of breakpoint (e.g. a C# breakpoint would not be valid if
there are no sessions being controlled by a C# debugger).
c) A line breakpoint is not valid if the class is is within is not loaded
d) A line breakpoint is not valid if there is no debugging information
associated with the method that the line is within, even when the
class is loaded.

Breakpoints that are not valid should also have a tooltip which
indicates that they are not valid, and perhaps offer some indication
of why (e.g. "Invalid Breakpoint - Perhaps this class isn't loaded in
the VM or wasn't compiled with debugging informatino.")

Note 1: I'm not sure D is actually possible, because currently
breakpoints are shown as valid in these cases.

Note 2: Ideally, breakpoints that concern themselves with class
unloading, for example, shouldn't be valid until the associated class
has been loaded.  Similarly, method breakpoints that name a specific
class shouldn't be valid until that class has been loaded.  However, I
also do not know if all of these cases can be caught.


PLACING BREAKPOINTS
If the user places a line breakpoint in a class which has been loaded
but has no debugging information, the breakpoint should be added
anyway (and, of course, marked as invalid). In these cases, we would
also show an alert that says something like: "The breakpoint you have
created is marked as 'invalid' because there is no debugging
information associated with the class loaded in the VM so the
debugger".  I don't think there should be a "don't show me this again"
checkbox (both because it adds another option to the options dialog,
and because this will not happen very often) 

Tho has a problem with breakpoints:
> A breakpoint has hit - but I don't know which one. It would be nice
> if handlers in the breakpoints list had a different icon when
> they have been triggered.

This is described in issue #34242.

*** This issue has been marked as a duplicate of 34242 ***

verified duplicate (and fixed therein)