mirror of https://github.com/zulip/zulip.git
09cf339c2b
We treat these exceptions the same way we treat fatal errors: report the error message to our server and then allow the exception to reach the top level. We could also override document.onerror, but don't. There are a couple of ramifications of this: * Exceptions caused by event handlers directly attached to DOM elements aren't handled * Exceptions caused by code at the top level that triggers an error (such as parse errors in our Javascript files) aren't handled The reason we don't override document.onerror is because the document.onerror handler has a limited interface and doesn't receive the exception object. It only gets the message, file, and line number of the error. Additionally, exceptions that we allow to propogate out of blueslip trigger an onerror event when they're never caught. In order to avoid handling the error twice (once by blueslip and once by the onerror handler), we'd have to encode the fact that the error has already been handled in the error message, which is pretty ugly. (imported from commit 7f049ae519dc198a9f7cfd41fd5dd18e584bd061) |
||
|---|---|---|
| api | ||
| assets | ||
| bots | ||
| certs | ||
| confirmation | ||
| humbug | ||
| servers | ||
| templates | ||
| tools | ||
| zephyr | ||
| .gitignore | ||
| manage.py | ||