Since this issue is a feature marking it as untriaged

Note that a work-around would be to have "Pause on caught exceptions" on and suppressing known exception sources (e.g. in frameworks) via anti-breakpoints, i.e. "Never pause here" in the context menu).

kozyatin...@chromium.org, sure, as I mentioned here:

>>>Yes, it's possible to check "Pause on exceptions" and "Pause on caught exceptions". But too many libraries and different custom code throws exceptions as the part of normal code flow (they do in intentionally). So debugging the code all the time having those options on, is really annoying. Even using "Never pause here".

* Sorry, I should have mentioned caseq@chromium.org, and not kozyatin...@chromium.org

If you use framework and wouldn't like to pause on caught or uncaught exceptions inside in framework code, you can blackbox source of this framework. I prefer reliable implementation of blackboxing (it's reliable enough for this case already, we're working on fixing current blackboxing-related issues) than additional settings checkbox and huge amount of logged console messages (and performance regression when DevTools is shown).
Please try it (for js fiddle you need to add //# sourceURL=something.js comment and then left click in related source and "Blackbox script", does it work for you?

kozyatin...@chromium.org, it might be ok for developers who work on the same web site the long period of time. In that case they blackbox files and set "never pause here" for some time. Then at some point they can cover all cases they need and next time DevTools remember breakpoint, knows all blackboxed file locations.

But in my case I switch different web sites often. The file locations are different (can't use the same pattern for all the files I don't want to stop on), the URLs are different (DevTools doesn't remember breakpoints when URL is different).
So using the approach you suggested I need blackbox and "never pause here" all the time in order to catch really rear type of the bug (when the exception is caught silently). 
Instead having the feature I request implemented, let me do nothing in that context (no blackboxing, no "never pause here"). I will just need to check Console time to time.

The problem with blackboxing a file is that sometimes you do not want to break on caught exceptions in its initialization, but you want to break on caught exceptions when its functions are later called (example - polyfills).

Another problem with blackboxing is that sometimes there is a race condition that results in a caught framework exception. When you use "Pause on caught exceptions" (without blackboxing the framework, because the exception might be there), the race condition never happens (due to unrelated caught exceptions), so you cannot debug it this way at all.

The second problem I mentioned is happening to me right now. I am using React, Babel, Webpack and browser-sync. That means that when I change some code, the page is automatically refreshed. Every few automatic refreshes, React is not rendering the content. No exception (probably caught), nothing. If I enable "Break on caught exception", React always renders the content.

I believe that we have couple already mentioned workarounds:
- blackboxing,
- never pause here.

We can make it better by adding condition for pause on exception, see crbug.com/862421 . Condition might be exception instanceof TypeError or exception.stack.includes('something'), at the same time condition might just log error and return false to ignore pause, e.g., console.log(exception),false.