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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
