From 251ba2d4c2dbd8b2e40d53699c2ba5446a55638d Mon Sep 17 00:00:00 2001 From: Georgios Kalpakas Date: Sun, 28 Sep 2014 17:48:27 +0300 Subject: [PATCH 1/2] docs($exceptionHandler): add a note about cases when exceptions are not delegated to the $exceptionHandler Add a note in $exceptionHandler's documentation about cases when exceptions are not delegated to the $exceptionHandler, because they are executed outside of the Angular context. Most notable such cases being the DOM event listeners registered using jqLite's/jQuery's on/bind methods. Closes #7909 --- src/ng/exceptionHandler.js | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/ng/exceptionHandler.js b/src/ng/exceptionHandler.js index 8899bf39984b..95ba9001e244 100644 --- a/src/ng/exceptionHandler.js +++ b/src/ng/exceptionHandler.js @@ -27,6 +27,18 @@ * This example will override the normal action of `$exceptionHandler`, to make angular * exceptions fail hard when they happen, instead of just logging to the console. * + *
+ * Note, that code executed outside of the Angular context does not delegate exceptions to the + * {@link ng.$exceptionHandler $exceptionHandler}. Some common such cases include functions invoked + * by third party libraries and callbacks associated with XHR, setTimeout/setInterval and browser + * DOM events (including callbacks registered using jqLite's/jQuery's `on`/`bind` methods). + * For some of those cases, Angular provides native wrappers that transparently manage the $digest + * cycle and delegate exceptions to the {@link ng.$exceptionHandler $exceptionHandler} (e.g. + * {@link ng.$http $http} for XHR, {@link ng.$timeout $timeout}/{@link ng.$interval $interval} for + * setTimeout/setInterval). For the rest, you can explicitly ensure that the code is excecuted + * inside of the Angular context, by wrapping it in + * {@link ng.$rootScope.Scope#$apply scope.$apply()}. + * * @param {Error} exception Exception associated with the error. * @param {string=} cause optional information about the context in which * the error was thrown. From f2a5402807d7c5c812d889bf30da212c04895e50 Mon Sep 17 00:00:00 2001 From: Georgios Kalpakas Date: Thu, 9 Oct 2014 18:32:07 +0300 Subject: [PATCH 2/2] docs($exceptionHandler): shorten note about exception-handling in event callbacks --- src/ng/exceptionHandler.js | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/src/ng/exceptionHandler.js b/src/ng/exceptionHandler.js index 95ba9001e244..4363ed4f206e 100644 --- a/src/ng/exceptionHandler.js +++ b/src/ng/exceptionHandler.js @@ -28,16 +28,12 @@ * exceptions fail hard when they happen, instead of just logging to the console. * *
- * Note, that code executed outside of the Angular context does not delegate exceptions to the - * {@link ng.$exceptionHandler $exceptionHandler}. Some common such cases include functions invoked - * by third party libraries and callbacks associated with XHR, setTimeout/setInterval and browser - * DOM events (including callbacks registered using jqLite's/jQuery's `on`/`bind` methods). - * For some of those cases, Angular provides native wrappers that transparently manage the $digest - * cycle and delegate exceptions to the {@link ng.$exceptionHandler $exceptionHandler} (e.g. - * {@link ng.$http $http} for XHR, {@link ng.$timeout $timeout}/{@link ng.$interval $interval} for - * setTimeout/setInterval). For the rest, you can explicitly ensure that the code is excecuted - * inside of the Angular context, by wrapping it in - * {@link ng.$rootScope.Scope#$apply scope.$apply()}. + * Note, that code executed in event-listeners (even those registered using jqLite's `on`/`bind` + * methods) does not delegate exceptions to the {@link ng.$exceptionHandler $exceptionHandler} + * (unless executed during a digest). + * + * If you wish, you can manually delegate exceptions, e.g. + * `try { ... } catch(e) { $exceptionHandler(e); }` * * @param {Error} exception Exception associated with the error. * @param {string=} cause optional information about the context in which