Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105628
MIME-Version: 1.0
References: <CAOkcCt-3OEKmsQVam=t-XSs7R-bNTDwLrLMT45QDauh_=nBCJA@mail.gmail.com>
In-Reply-To: <CAOkcCt-3OEKmsQVam=t-XSs7R-bNTDwLrLMT45QDauh_=nBCJA@mail.gmail.com>
Date: Tue, 7 May 2019 17:09:38 +0200
Message-ID: <CAF+90c_VLf2RsfpTqjpfmEFxzpMkMt3MYe3euZVYYBZS7mOn7Q@mail.gmail.com>
To: Gert <gertp93@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000f725405884d9c24"
Subject: Re: [PHP-DEV] Error instead of returning false
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000000f725405884d9c24
Content-Type: text/plain; charset="UTF-8"

On Tue, May 7, 2019 at 4:22 PM Gert <gertp93@gmail.com> wrote:

> Hello internals,
>
> I wanted to propose an RFC, but i'd like to check first if this idea
> has been considered before already.
>
> 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.
>
> Currently, functions like getcwd or json_decode will return false/null
> when an error occurs, and they populate a global error state, which
> can be retrieved by error_get_last, or similar functions. json_decode
> already got the JSON_THROW_ON_ERROR option in PHP 7.3, and this RFC
> would basically make that behaviour default. This RFC would target PHP
> 8.0, but i'd like to hear some opinions on this.
>
> Greetings,
> Gert de Pagter (BackEndTea)


There's two cases to distinguish here:

1. Error conditions that indicate a programmer error (what we would throw
an Error exception for nowadays).
2. Error conditions that indicate a data/environment/etc error (what we
would throw an Exception exception for nowadays).

One large category of warnings of the first kind has already been converted
to TypeErrors in https://wiki.php.net/rfc/consistent_type_errors. And I'd
be in favor of changing more of these in PHP 8. This is (relatively)
non-intrusive from a BC perspective, because these conditions are not
something you should ever explicitly check for: If your code hits them, it
is simply broken.

However, what you seem to have in mind here are error conditions of the
second kind. I don't think we can change these on any timeline. Current
code (that is careful about handling errors) will be checking false/null
return values for them, and throwing an exception instead would be a major
and very hard to automatically fix BC break.

The proper way (imho) to handle an eventual migration to exceptions is to
introduce new APIs that supersede the existing ones. E.g. if we ever get
around to introducing an OO API for the stream layer, than that would be
the time to also introduce use of exceptions.

A possible alternative would be to control this behavior in some way
similar to declare(strict_types).

Regards,
Nikita

--0000000000000f725405884d9c24--