How can we verify the above comment is no longer relevant?

Can you add some tests to verify this?

I do not know if the above comment is relevant or not. I do know that this @-suppression supress ALL php errors that is ever generated by PHP (inside event handler) which is very bad

I understand, but if fix this now we should make sure to avoid any regressions in the future.

Can you add some tests to verify this?

I've did some tests today but i can't reproduce this. The comment in reactphp/reactphp#234 (diff) is also not clear in what exactly produces these warnings. Maybe @nrk or @jmalloc can shed some light on this.

I agree that the @ is really bad here because it also supresses any warnings and errors from the callbacks.

IIRC, the initial problem was that EventBase::loop() emits an (additional?) warning after an error in a user-defined callback. So, perhaps calling trigger_error() in a timer function, or something like that would reproduce it. I can't recall if I witnessed this myself, but I kept the @-suppression at @nrk's request.

I can see where this warning might be an issue, especially when using a strict error handler, but it's arguably the responsibility of the user to handle/suppress any such errors in callbacks. So as long as we're not producing them in the loop implementation ourselves it's probably OK to remove the @.

In the meanwhile I can open an issue on pecl-event to let the author know about this.

Yes, pushing this upstream is where this should be addressed in the first place! 👍

I'd say it's better to have additional warnings than suppressing everything.
[…]
3. Remove the @-suppression and document the change and it's impact in the changelog

Absolutely agree here! 👍

Given this only triggers when an uncaught warning or exception is passed through, I expect this to have very little impact in actual consumer code. After all, this is something that should never happen in the first place. Also, this only triggers an additional warning, so I agree this should be safe to add regardless 👍

This means that even if upstream takes longer to fix this and this be inconsistent across different upstream versions, I think it makes perfect sense to get this in now already 👍

Given this only triggers when an uncaught warning or exception is passed through, I expect this to have very little impact in actual consumer code.

@clue the additional warning is emitted even when the exception is caught, see the example in my previous comment.

@jsor alright will do tomorrow first thing in the morning!

@nrk Are you still planning to file an issue in the pecl-event repo? Otherwise i can do it.

@clue the additional warning is emitted even when the exception is caught, see the example in my previous comment.

Yes, but only if the exception bubbles up to the $this->eventBase->loop() call. This usually results in an uncaught exception anyway since in almost all cases $loop->run() is called at the end of the script.

@jsor sure that's still my plan, actually I was modifying the extension myself to test this change and eventually have a PR ready if the author agrees, just ended up having unexpected stuff going on at work so couldn't do it yet. As for uncaught exceptions: yes and I realized later that I misinterpreted what @clue meant with passed through.

sure that's still my plan, actually I was modifying the extension myself to test this change and eventually have a PR ready if the author agrees, just ended up having unexpected stuff going on at work so couldn't do it yet.

No hurries, very appreciated 👍