If you are debugging JavaScript using the web inspector that would cause an exception to happen and you have pause on exceptions enabled, but it is within a try/catch block, the debugger still pauses on it.
To be more in line with other debuggers (including the Dashcode debugger), the web inspector should not pause on an exception if it is caught.

Created attachment 38390[details]
proposed patch
This patch gets us the proposed behavior. It waits to see until function exit if an exception still remains - one won't remain if we caught it.
I am not sure what the exception() callback should do if we don't pause anymore.

I disagree, in all debuggers for other languages, pause on exceptions means pause on all exceptions, regardless as to whether there is a handler. Pause on exceptions is used specifically for the case where you want to pause on an exception they may actually be caught.

Rather than looking at things like dashcode, people should be looking at real debuggers such as VS, Eclipse, etc, where (if memory serves) th debugger stops on uncaught exceptions by default, and pause on exceptions actually means pause on all exceptions whether or not there is a handler.

Comment on attachment 46965[details]
[PATCH] Fix
This patch as-is will likely change behaviour in Dashcode or other clients. They might rely on the exeption function always being called.
Since those clients are protected from the C++ layer, I propose we pass another bool to the function: hasHandler.
Then the Debugger can decided if it cares about the exception, and it lets up have a setting. It will also prevent breaking other clients. (You will need to update WebScriptDebugger.mm in WebKit to prevent breaking the build when you add the new argument.)

Created attachment 46967[details]
[PATCH] Add a hasHandler parameter to JavaScriptDebugServer::exception
This patch has no change in behavior, but enables us to differentiate between Break on All Exceptions and Break on Uncaught Exceptions.

Comment on attachment 46967[details]
[PATCH] Add a hasHandler parameter to JavaScriptDebugServer::exception
I think you need to "UNUSED_PARAM(hasHandler);" in WebScriptDebugger too. The rest of the code looks correct, though.
FWIW, I agree with Oliver about this feature: DashCode's behavior is odd. Maybe we could add a tri-state button. But have any real users requested one?

Created attachment 47083[details]
[PATCH] Tri-State Button + Tim's Comments
This renames the functions to pauseOnExceptionsState, and takes care of other feedback from Tim. Also waiting on feedback from Pavel before landing.

Comment on attachment 47083[details]
[PATCH] Tri-State Button + Tim's Comments
> get toggled()
> set toggled(x)
You should renamed these too. But that will touch more files. Maybe add a get/set state, and make toggled use that only for states == 2? And throw otherwise.

(In reply to comment #21)
> Created an attachment (id=47085) [details]
> [PATCH] Cleaned up toggled/state Getter/Setter code
>
> Should be a final pass, waiting for Pavel to take a look before landing. Sorry
> about the numerous iterations.
We are now fixing Chromium so that it works with this patch. Will land this one shortly!

(In reply to comment #24)
> (In reply to comment #21)
> > Created an attachment (id=47085) [details] [details]
> > [PATCH] Cleaned up toggled/state Getter/Setter code
> >
> > Should be a final pass, waiting for Pavel to take a look before landing. Sorry
> > about the numerous iterations.
>
> We are now fixing Chromium so that it works with this patch. Will land this one
> shortly!
Let me know when you land it, I can land my part when it's ready. Thanks for following up on this.