Re: [PHP-DEV] Re: Error instead of returning false

  105634
May 7, 2019 19:57 gen.work@gmail.com (Eugene Leonovich)
On Tue, May 7, 2019 at 5:14 PM Mark Randall <markyr@gmail.com> wrote:

> On 07/05/2019 15:22, Gert wrote: > > My idea, extremely summarized, would be to take the functions that > > return false/null when they 'error', and instead make them actually > > throw an error. > > It comes up on various discussion forums every other month. There's a > few downsides to it, but mainly that any existing error handling would > need to be re-written as tests for the false value would never be > reached after the exception was thrown. > > It's a bit less of a hassle for more modern PHP design practices, as any > warnings are globally promoted to exceptions using set_error_handler in > userspace, but this too has its problems (for example in third party > libraries). > > IIRC, most functions are at least checking their input argument types > now and throwing InvalidArgumentExceptions, and the odd few like > json_decode have their exception behaviour, provided its flagged. The > new security focused stuff always throws (such as if there's not enough > entropy available). > > I don't think it's in any way practical to add throw-or-not flags to > every other internal function that could error out, and so there are 4 > options that I can see: > > 1. Make no change. > > 2. Everything throws. People have to re-write. The compiler would > probably need to further inspect the AST at compile time, and throw a > depreciation warning if the result of an error-able internal function > was tested for false. > > 3. Class (or namespace) level declares to throw on internal function > errors. > > 4. Leave the existing functions as-is, finally claim the \php namespace, > alias all of the internal functions into it, and make their default, > unchangeable behaviour be to throw a RuntimeException on error. > > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > For the record, there is already a library for option 3:
https://github.com/thecodingmachine/safe Another option would be to introduce a new declare directive, something like