UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
My environment is mostly Meteor+Angular 2, but this applies to most other stuff as well. A LOT of frameworks throw a bunch of errors initially intentionally. They are polyfill checks, browser behavior checks, startup routines built on expecting errors etc. For example, these all throw for me on startup
- meteor (~18 errors)
- ecmascript-runtime (16 errors)
- jQuery 2 errors
- JSON3 1 error
- zone js 3 errors

This makes using "Pause on caught exceptions" very hard, since I always have to click "Continue" 40 times before I get to the "real code". So, do I have to use it? Yes, most code nowadays run in some kind of try/catch (typically a Promise). Which means that whenever I come to some kind of error handler (could place a breakpoint/debugger statement there), the error origin is lost for variable inspection etc. So what I typically do is untick the checkbox, and when my app has loaded I tick it again.

I have some different suggestions on how to improve this
1. Improve blackboxing by either automatically don't pause at all for exceptions originating from blackboxed scripts, or have a config per blackboxed scripts on whether "Pause on exception" applies AT ALL on errors originating from the script. Today's behavior is to pause on the last frame calling into the blackboxed script, which is of little help. The downside with this approach though is that although blackboxing e.g. jQuery helps, I really don't WANT to blackbox jQuery for other reasons than blocking initial errors, which makes blackboxing a rather crude tool.
2. Add a way to say "Never pause for this" when pausing on a caught exception. Suggestion: a button below the error description. I imagine the dev tools would then keep a list of origin/line/column and filter on that. Downside with this is I guess you need some kind of pane somewhere to manage these exceptions (like blackboxing or breakpoints). The concept could also be combined with blackboxing, to have "Blackbox line" or "Blackbox code point", together with the feature in 1. Blackboxing parts of scripts could be useful for other purposes as well.
3. A feature similar to above, but instead of storing code locations, just maintain a list of regexes matching error messages. Thus list could be put away somewhere if desired and just be matched against. The downside here is that often frameworks rethrow other exceptions. The same exception could be thrown about 4/5 times, of which only 1 is relevant. You want to block those other places, but that's hard given just regex matching.
4. Some API to turn "Pause on caught exceptions" on and off. Thus you could enable the checkbox when your app's setup has run. This could be exposed to the normal page, or maybe more reasonably, the chrome dev tools. That would then require an extension to be installed that communicates with the app somehow. Downside with this is that irrelevant exceptions might occur after setup as well (e.g. not matched route segments in Angular router).

I would personally much prefer 2. as that would solve all problems. The others wouldn't.

What do you think?

What is the expected behavior?

What went wrong?
N/A

Did this work before? N/A 

Chrome version: 57.0.2986.0  Channel: canary
OS Version: OS X 10.12.2
Flash Version: Shockwave Flash 24.0 r0