On Tue, May 7, 2019 at 4:22 PM Gert <gert...@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
