unmentioned problem with work around concerning unhandled exception

[jhv2017kam]

The motivation fails to mention that the shown workaround kind of breaks the "break on unhandled exceptions" feature supported by some debuggers. Since from the debuggers point of view not only ConflictError but any Error or derived is handled

[ljharb]

… and anything that doesn't match the catch guard gets rethrown, so it shouldn't break anything.

[jhv2017kam]

I under stand that. My point was that as thing is today you are forced to use the mentioned workaround. Unfortunately that mean if you check "break on unhandled exception" in chrome debugger all exception will be considred handled if they go through the workaround code. Which is typical not what you want. So I sugest that senario is mentioned as an benefit of implementing this proposal too .

[ljharb]

That doesn’t sound correct - they’d all be handled, but whatever subset isn’t “caught” would be rethrown and thus become unhandled again.

[theScottyJam]

I would be surprised if a debugging tool considered an error to be "caught" if the error didn't match any of the catch patterns in the try-catch. Conceptually, the error just passes right through, without being caught by any of the catch blocks.

[ljharb]

@theScottyJam yes, but the OP is talking about the pre-catch-guard workaround - which requires an explicit rethrow, which should thus be considered "uncaught".

[theScottyJam]

Ah, yes, right

[jhv2017kam]

@ljhard yes it become unhandeled again but it don't break at original throw location but at the rethrow location and that seldom gives insight in to the problem. Sorry for missing that detail in the initial description

Actualy my thought was similar to @theScottyJam

I would be surprised if a debugging tool considered an error to be "caught" if the error didn't match any of the catch patterns in the try-catch. Conceptually, the error just passes right through, without being caught by any of the catch blocks.