On 16 December 2022 21:34:16 GMT, Theodore Brown <theodor...@outlook.com> wrote: >On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans <der...@php.net> wrote: > >> Hi, >> >> I've just opened the vote for "More Appropriate Date/Time Exceptions". >> It runs until December 31st, 24:00 UTC. >> >> You can vote at: >> https://wiki.php.net/rfc/datetime-exceptions#voting > >Hi Derick, > >Thank you for your work on this. I like the idea of having more specific >exceptions to avoid having to parse generic exception/warning strings. > >However, I voted No because there doesn't seem to be an implementation >currently, and I'm concerned about introducing differences in error >handling between the procedural and object-oriented date functions. > >Is there a rational for why the procedural date functions should continue >producing generic warnings/exceptions, rather than consistently using the >same exception hierarchy as the OO interface? I fear this could make it >harder for users to switch between the procedural and OO APIs, as some >errors might have to be handled in a different way. > >Also, could maintaining parity between the procedural/OO APIs be more >difficult if they each implement error handling differently? >Perhaps I'm mistaken, but I thought that currently the procedural date >functions are simple aliases of the corresponding object method.
You're mistaken then. The procedural versions never threw exceptions, and changing to that now is a big BC break, which is not warranted. It was always a deliberate choice (since 2014) that the procedural versions don't throw exceptions, and the OO versions do. The RFC is not wanting to change this behaviour. And rightfully so. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
