Bug #127835 for IO-Async: Global loop exception handling

Wed Nov 28 18:07:25 2018 DBOOK [...] cpan.org - Ticket created

Subject:

Global loop exception handling

There's currently no way to add exception handling to all loop callbacks in order to prevent the loop being stopped by an exception. A possible method would be to allow an on_error event handler to be specified for the loop, and if unspecified this would fallback to the current behavior.

Thu Nov 29 05:40:35 2018 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Wed Nov 28 18:07:25 2018, DBOOK wrote: Show quoted text

> There's currently no way to add exception handling to all loop > callbacks in order to prevent the loop being stopped by an exception. > A possible method would be to allow an on_error event handler to be > specified for the loop, and if unspecified this would fallback to the > current behavior.

(as discussed on IRC:) Yes this sounds useful behaviour. Probably the way forward is to add a `->configure` method to IO::Async::Loop (and while we're there, migrate the `set_resolver` ability to it) -- Paul Evans

Thu Nov 29 05:40:36 2018 The RT System itself - Status changed from 'new' to 'open'

Wed Jan 09 19:02:50 2019 leonerd-cpan [...] leonerd.org.uk - Severity Wishlist added

Mon Apr 15 15:28:40 2019 leonerd-cpan [...] leonerd.org.uk - Correspondence added

$loop->configure( on_exception => sub { ... } ); Still need to design what arguments it receives -- Paul Evans

Mon Apr 15 16:07:01 2019 DBOOK [...] cpan.org - Correspondence added

Prior art for posterity: POE - exceptions send a fake 'DIE' signal to the kernel, which can be handled by a session and is passed several arguments pertaining to the state of the kernel when the exception occurred. If CATCH_EXCEPTIONS is disabled, events are not run in an eval. https://metacpan.org/pod/POE::Kernel#Exception-Handling EV - exceptions are passed to $EV::DIED, a global coderef which defaults to warning "EV: error in callback (ignoring): $@" and uses $@ directly. Events are always run in an eval and exceptions in $EV::DIED are ignored. https://metacpan.org/pod/EV#$EV::DIED Mojo::IOLoop - exceptions emit an error event on the Mojo::Reactor of "$what failed: $@" - where $what is a brief label of the handler that failed. Error event is fatal by default on its own but Mojo::IOLoop sets up a handler that warns "$reactor_class: $exception" instead. I think that the Mojo::IOLoop strategy is most similar to a reasonable approach for IO::Async::Loop.

Mon Apr 15 16:08:49 2019 DBOOK [...] cpan.org - Correspondence added

On Mon Apr 15 16:07:01 2019, DBOOK wrote: Show quoted text

> Mojo::IOLoop - exceptions emit an error event on the Mojo::Reactor of > "$what failed: $@" - where $what is a brief label of the handler that > failed. Error event is fatal by default on its own but Mojo::IOLoop > sets up a handler that warns "$reactor_class: $exception" instead.

Addendum: events are always run in an eval, and the relevant documentation: https://metacpan.org/pod/Mojo::Reactor#error