A way of explicitly reporting exceptions
bzbarsky at MIT.EDU
Mon Jun 23 12:44:40 PDT 2014
On 6/23/14, 3:35 PM, Kevin Reid wrote:
> Yes, but setTimeout may be less prompt than you want depending on the
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
More information about the es-discuss