> On 21 Nov 2014, at 03:02, Adam Harvey <ahar...@php.net> wrote: > >> The problem is that it’s the least bad of the available options. > > I disagree. To my mind, the best option right now (barring the status > quo, which realistically I'd prefer) would be the try_* functions > only. They line up with how ext/standard (and pretty much all of PHP > other than a smattering of OO functions and SPL) signal errors, and > avoid duplication. I don't really fancy explaining the difference > between to_* and try_* in ##php to a new developer. > > PHP may be a mishmash of undesigned APIs in places, but that doesn't > mean we should dump fuel on the fire by adding two parallel APIs that > are named obscurely and differ only in how they signal errors. > > There's no function in php-src today that throws an exception outside > of an OO context. (Indeed, if you go through the various classes and > methods in php-src, I suspect even _in_ an OO context the majority of > errors are signalled via return values or PHP errors.) > > Right now, the standard for appropriateness when adding an exception > is pretty much "is this an error generated in an OO context"? This > clearly isn't. > > To be clear: if a way could be designed to do it without shredding BC, > I'd be ecstatic if we deprecated our current error handling system > entirely in favour of exceptions in PHP 7. But that's not the standard > right now, and an unrelated RFC like this isn't the place to make that > decision. > > Why would you throw an E_RECOVERABLE_ERROR? The error's been > signalled: the function returned NULL, rather than an > int/float/string.
try_ serves a different use case to to_. to_ is mostly supposed to be a last line of defence. The only reason it's any safer than an explicit cast is that it throws an error that will halt execution if it goes unhandled. If you have to explicitly check for an error, that means people won't, and the aim of making safer casting as convenient as unsafe casting will not have been achieved. So, the alternative would be an E_RECOVERABLE_ERROR. try_ exists so you can use the to_ functions in a validation context, where exceptions shouldn't be used for flow control. Of these two sets of functions, if I have to get rid of one, it'd be try_. Also, a special note: to_/try_string is particularly useful if you want to gracefully handle casting of objects which lack __toString to a string, one of the only cases currently where an explicit cast can fail. There's currently no way to do this aside from checking for the existence of __toString, which isn't necessarily correct as an internal class can allow casting to string without defining that method. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
