Wrong defer watcher try / catch about amp HOT 6 CLOSED

@bwoebi After thinking about this, I realized an app might have a IO, timer, or signal that continually throws that might block another watcher from ever executing that would stop the cycle. I'll update everywhere watcher callbacks are invoked to be wrapped by their own try / catch blocks and continue the tick after calling the loop error handler.

from amp.

That try / catch block catches exceptions thrown from any watcher invocation, not just defers, as it is also around the call to dispatch. Any watcher callback throwing an exception effectively immediately ends the tick. In this way defers are handled the same as any other watcher.

from amp.

It makes handling easier, but it won't execute any I/O watchers if there's always one defer throwing.

from amp.

I can't imagine that happening in an actual app.

from amp.

Same here, that'd be an extreme edge case, but it might happen, as we use Loop::defer to rethrow errors from promises.

from amp.

I see no reason why this shouldn't be changed...

from amp.