Re: [RFC] Extend error control operator to suppress exceptions

> On Mar 4, 2021, at 9:08 AM, G. P. B. <george.banyard@gmail.com> wrote: > > Hello internals, > > This new RFC which I'm proposing is to extend the capability of the error > control operator @ to not just suppress diagnostic messages but also > exceptions. > It can currently be found on GitHub: [1] > > https://github.com/Girgias/error-control-operator-exceptions-rfc Reading it several times, it is still not clear to me what the following means from the Proposal section: ------------------------- Add the following syntax @<union_class_list> to suppress only the exceptions within the class list, this is similar to: try { expression } catch (union_class_list) {} As such @<\Throwable>expression and @expression are identical. ------------------------- Specifically: 1. What @<union_class_list> means and what it would look like in practice, 2. What catch(union_class_list) would look like in practice, 3. What @<\Throwable>expression means and what it would look like in practice, and 4. Can you provide a few concrete code examples, please? > The main motivation for this is to provide a path to migrate in a backwards > compatible manner away from diagnostics such as E_WARNING to the use of > exceptions without breaking 99% of PHP code which has been written in the > last 25years. I am not clear what you mean by "providing a path to migrate in a BC manner" here. Would this require developers to prefix all functions calls with @ for functions changed in a future version of PHP to throw exceptions instead of returning values, assuming they do not have the green light from their stakeholders to make more substantive changes to their code? IOW, are you proposing a requirement to change existing code but in a form that could be (almost?) completely automated? Is that the how you are envisioning this aspect of BC to work? > This proposal on it's own would not be sufficient to trigger such a change > for extensions but in combination with another proposal to introduce a > throw_on_error declare [2] it could provide a bridge for a > gradual > transition to the use of more exceptions internally. Would you also consider adding a reciprocal error_on_exception declare? > Although I'm not thrilled with the idea of shoving more functionality into > @ I don't see any other way, and thus I think it a necessary evil to > improve the long term health of the PHP project. What do you see as the downside of shoving more functionality into @? Is the concern anything more than making the source for PHP more complicated to maintain? > Feedback on this RFC and different ideas on how to tackle this topic are > highly appreciated and welcomed. > > Best regards, > > George P. Banyard > > [1] > https://github.com/Girgias/error-control-operator-exceptions-rfc > [2] Draft RFC for throw_on_error declare > https://github.com/Girgias/php-rfc-throw-on-error-declare -Mike