Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105634
MIME-Version: 1.0
References: <CAOkcCt-3OEKmsQVam=t-XSs7R-bNTDwLrLMT45QDauh_=nBCJA@mail.gmail.com>
 <5cd1a0cc.1c69fb81.84b00.b914SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5cd1a0cc.1c69fb81.84b00.b914SMTPIN_ADDED_MISSING@mx.google.com>
Date: Tue, 7 May 2019 21:57:18 +0200
Message-ID: <CADqioP25oW_vpo+y+mBUn-zHjPvVApjvTVvzBE+f=eJTOBUJxQ@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005f25da058851a189"
Subject: Re: [PHP-DEV] Re: Error instead of returning false
From: gen.work@gmail.com (Eugene Leonovich)

--0000000000005f25da058851a189
Content-Type: text/plain; charset="UTF-8"

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

<?php

declare(throw_on_error=true);

$json = file_get_contents('foobar.json'); // will throw



-- 
Thank you and best regards,
Eugene Leonovich

--0000000000005f25da058851a189--