A way of explicitly reporting exceptions

[Boris Zbarsky]

On 6/23/14, 3:35 PM, Kevin Reid wrote:
> Yes, but setTimeout may be less prompt than you want depending on the
> application

Note that at least in some browsers window.onerror is called off an 
event loop task anyway.

> However, I'd like to propose a different facility: Instead of "catch and
> then report", have a "try and stop propagation but don't catch".

We could do something like this, effectively keeping the reporting magic 
hidden as now.  It doesn't go as far in terms of explaining the 
platform, etc, but does provide the minimal amount of leeway we need here.

> This has a nifty advantage in debuggability: you can declare that a
> debugger's "stop on uncaught exception" should stop on such errors
> _before the stack is unwound_.

Note that such a facility would still fail in cases when a catch 
examines and then rethrows an exception, and in fact allows observably 
detecting whether an exception is caught and rethrown or just not 
caught.  This actually affects one web platform spec algorithm (the node 
filter for treewalker/nodeiterator), which is currently specified to 
catch-and-rethrow.

-Boris