On Thursday, July 26, 2018 1:36:25 PM CDT Daniel Plainview wrote: > > should require to catch all kind of exceptions/errors for "true" event > > listeners > > Maybe I wasn't clear enough, just to be precise: I mean, implementation of > EventDispatcher must not rethrow any exceptions/errors from event > listeners, all executors of async event listeners must not stop work if > event listener fails. > They should log error, but as I said, correct implementation must behave > like event listeners are somewhere in separate process, > > In other words, event listener is not connected to the original call stack > in general and the caller is not responsible for this.
That's a good point, and another case where the notify and modify pipelines behave differently. I can totally see where for a modify event you would want an exception to bubble up, but you're right that for a notify event it should not. We haven't really talked about error handling much yet, but I've added it to the agenda for our next meeting. An interesting approach that the Node event handler we looked at took was to catch exceptions and convert them to another event type, on which you can register listeners to act as error handlers. I'm not sure if that works well for the modify events. Probably not for notify events, but modify maybe. Thoughts? --Larry Garfield -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2548864.Rs9vMCEuQa%40vulcan. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
