Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107612
To: PHP internals <internals@lists.php.net>
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
 <CAH0Uv3FfJ=6LN=whewRs0WswxLXN6TSRXWyUaNYCwYsTp81d9A@mail.gmail.com>
 <CAG9XoMRT=iMKuxDCJW=zWbzm10BFFoKMLVx3aVrUGYbzs1KdMg@mail.gmail.com>
Message-ID: <6fa02cb5-b474-4b36-4e0f-89679475e250@gmail.com>
Date: Mon, 21 Oct 2019 19:46:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAG9XoMRT=iMKuxDCJW=zWbzm10BFFoKMLVx3aVrUGYbzs1KdMg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: rowan.collins@gmail.com (Rowan Tommins)

On 21/10/2019 18:45, Benjamin Morel wrote:
> I personally like exceptions in all cases, as they allow for 
> fine-grained error handling, for example:
>
> ```
> try {
>     mkdir('somedir');
> } catch (FileExistsException $e) {
>     // only catch *this* exception, which my program expects,
>     // let any other exception (say a PermissionException or a generic 
> IoException) bubble up!
>     // this *is* what you want: it will be caught by your top-level 
> exception handler which will log it to inform you that something is 
> wrong with your system
> }
> ```


I think this argument is something of a logical fallacy: just because 
exceptions are (or can be) more fine-grained than the current return 
value, that doesn't mean they're the best tool for the job.

If I'm remembering it correctly, an example is the old PEAR 
error-handling model, where rather than false, functions returned a 
PEAR_Error object. This could be just as fine-grained (using sub-classes 
or error code constants) as an exception, but without the additional 
behaviour of blowing through the stack.

In some cases, you can go one step further, and have a "result" object, 
with methods like isSuccessful(), getErrorCode(), and getOutput().

Importantly, this can and should be different for different functions.

In a previous message you wrote this, which I think mischaracterizes / 
misunderstands previous discussions:


> To play the devil's advocate, however, IIRC some discussions in the past
> mentioned that the BC breakage that comes with it is such an issue that it
> would be preferable to create a brand new API rather than attempting to fix
> the existing one.
> Nobody ever jumped in to propose such an API, though :-(


It's not that we need "a brand new API", singular, it's that some of the 
more complex sets of functions should be redesigned, with error handling 
considered as part of each design.

So, a new file-handling API could provide a much richer set of error 
codes for its equivalent of fopen(), which might or might not involve 
exceptions. It might instead have a file handle object which could 
represent closed and errored handles, so that attempting to open a file 
would always give the same result type, but would have information about 
what failed.

Meanwhile, if we were to design a new string API to make things more 
consistent, and perhaps introduce better Unicode support where relevant, 
that would be a good chance to throw exceptions for truly exceptional 
cases. However, we might also include more forgiving variants of 
functions, for "best effort" processing of user input (like iconv's 
//TRANSLIT and //IGNORE modes).


On the other hand, there are some errors where the answer to the 
question "would it be better to halt processing than continue in an 
unknown state?" is "yes", so it's reasonable to introduce an exception, 
even though existing programs aren't expecting it. But again, this 
should be considered for every case, not as a general rule that all 
Warnings should be promoted.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]