Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87185
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
 <55A63C90.8000705@gmail.com>
 <CAGa2bXYpZuYssDqLJxhaD0Cx-myNM_vXAOr-G2X4Y9xawbtmVA@mail.gmail.com>
Message-ID: <55A64B40.4000609@gmail.com>
Date: Wed, 15 Jul 2015 13:00:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYpZuYssDqLJxhaD0Cx-myNM_vXAOr-G2X4Y9xawbtmVA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: rowan.collins@gmail.com (Rowan Collins)

Yasuo Ohgaki wrote on 15/07/2015 12:20:
> Engine exception is a little different. The main motivation for engine 
> exception is
> to give a chance to users for graceful program termination. Functions 
> can achieve
> the objective by E_RECOVERABLE_ERROR mostly.

This is simply incorrect, as demonstrated by conversion of existing 
E_RECOVERABLE_ERROR states in the engine to Throwable, and nullified 
RFCs which would have, had EngineExceptions not passed, convert 
engine-issued E_ERRORs into E_RECOVERABLE_ERROR.

> If we are going to adopt exception for "functions", it would be better 
> to have
> switch that convert all errors to exceptions.

Strongly disagree. A runtime switch would be a horrible consistency 
nightmare for userland, and many of the existing functions which 
desperately need better error-handling (e.g. file I/O) don't issue an 
error at the moment anyway.

The only reason (and it's a massive reason, don't get me wrong) not to 
start throwing exceptions all over the core is backwards compatibility. 
New functions do not, by definition, have anything to be backwards 
compatible with.

So my suggestion is, to come up with some reasonable definition of "new 
area of functionality" where we can do things in a way which everyone 
seems to agree is basically better, i.e. throw Exceptions.
- The rule shouldn't apply for new variations or close cousins of 
existing functions (e.g. the json_decode_to() that was briefly discussed 
should use similar conventions to json_decode() if it were implemented), 
only in cases like this where we're adding a new set of functions (the 
manual puts random_bytes and random_int in their own "book": 
http://php.net/manual/en/book.csprng.php).
- It also shouldn't be used for "routine" errors (like File Not Found), 
only in place of conditions which can justify a fatal error - both for 
the intuitive reason that an uncaught exception *is* a fatal error, and 
the procedural reason that we may want to decide a policy for "routine" 
error handling at a later date.

At some point, we should revisit the general error-handling strategy of 
both the language and the core library, but 7.0 having been somewhat 
derailed (in my opinion) by the endless debates about scalar type hints, 
it will have to wait until 8.0 before we can do anything radical to 
existing functions.

Regards,
-- 
Rowan Collins
[IMSoP]