Currently, the IDE allows setting breakpoints on lines that are not executed, such as blank lines, comment lines, and subsections of an executable line that spans several lines in the IDE. None of these breakpoints will make the debugger stop, but since it is possible to set the breakpoint the IDE gives the impression as that it is OK.
I leave it up to the developers as to what to do when one does click the gutter at such a line. Showing a message that can be suppressed, doing nothing, or setting the breakpoint at the nearest possible line are some options. I can't argue vividly for any of them, but my least favorite would be to do nothing. That confuses people and quickly becomes the #1 question for support.

I agree with you on the point that just being able to set breakpoints everywhere is not really the ideal solution.
Although I think that the person debugging should think about what they are doing, and then so he/she won't even put breakpoints there.

However, your favorite solution of doing nothing is even more confusing than how it is now. I can guarantee you it will become a much bigger support issue if the IDE refuses to just put a breakpoint. A lot of people are going to think that something is broken then.
Showing a dialog is annoying so imho a no-no as well. The ideal method would just be to do what visual studio does: put the breakpoint on the first breakable line after the place where you want to put the breakpoint.

Blizz, I think you misread RamonS' post - he said doing nothing was his *least* favorite option, for the same reason you cited.

In any case, I agree that putting it on the nearest acceptable line is probably the best way to handle it. To help clarify to the user why it's happening, though, I think putting it on the line where they clicked and having it then visually slide down (or up) to the corrected location would be great.

Indeed, I seem to have missed the "least" word - sorry.


Personally I don't think the visual "sliding" is really necessary. It's fairly obvious that if you click line X and the breakpoint appears on line Y that line X is not executable. Should be pretty clear for everyone with a little logical reasoning imho

If it were that obvious, then I don't think people would be trying to set a breakpoint on a non-executable line to begin with. Nor do I think this topic would continue to come up over and over, nor do I think most IDEs would have bothered putting something in place to prevent ill-placed stops.

I think just having it show up somewhere else would confuse matters even more, since it might give the impression of the IDE simply not doing what you requested - a bug. Remember, the user hasn't yet realized that a line is non-executable. Heck, if the stop ends up one line up or down, the programmer could even think that they simply mis-targeted their click and proceed to immediately do it again. Further, depending on how familiar they are with the code, what level of programmer they are, and other factors, it may take quite a while for the user to reach that conclusion on their own, especially when they're focused on the fact that IDE just did something completely contrary to a requested action without any indication as to why.

It need not be overly fancy, just a simple, quick little animation to give a clue what happened. Remember, a friendly user interface is a Good Thing, and good UI design dictates that the user shouldn't have to draw logical bridges to figure out why a program just did something contrary to their very reasonable and very normal expectations.

I can imagine what type of software such developer will create. If he/she can not understand the simple idea of break point and where it could be placed.

IMHO he/she should understand the working principles of PHP and debugger. The decision to write PHP script means, you are not regular user any more, you are standing a bit higher, you are software developer.

I think the best solution will be to change color of the break point. For example if debugger could not stop on this point the red dot could be changed with green one.

A different colored stop would work, too, or perhaps one with a badge. Still gives a visual indication, and if an explanatory tool tip is shown on mouse-over, all the better.