Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126464
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 20 Feb 2025 16:42:28 +0100
To: Bilge <bilge@scriptfusion.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])
In-Reply-To: <e5edbe8f-5622-4f0d-9c07-aa0a797b9222@scriptfusion.com>
References: <a995ac24905030e168e7f6006b996cd5@bastelstu.be>
 <e5edbe8f-5622-4f0d-9c07-aa0a797b9222@scriptfusion.com>
Message-ID: <b3fc1f341aed90b9c8015b70bb4d2816@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Apologies for the delay in getting back to you. Volker was out of office 
and I try to coordinate the replies with him to not misrepresent his 
opinion.

Am 2025-02-12 14:17, schrieb Bilge:
> Apologies if this has already been brought up; I haven't read the 
> entire thread, but isn't the entire premise of this RFC based on a 
> falsehood?

We do not believe so.

>> This kind of “partial success” can only be reliably communicated by 
>> means of a return value
> 
> Exceptions are objects, so you can attach whatever additional 
> information you wish to that object.
> 
> Perhaps the word "reliably" is doing a lot of heavy lifting in that 
> sentence, but if you would refute me (which presumably you will), then 
> I think this needs to be explained in better detail in the RFC, because 
> it looks to me that exploiting object properties is just as viable as 
> returning something, and probably preferred, since this solves your 
> problem of the user not handling the failure.

Perhaps one can find a better word than “reliably” there, nevertheless: 
We disagree that throwing an Exception is an appropriate solution to 
communicate partial success. While it certainly would ensure that 
developers can't forget to handle the (partial) failure case, it would 
also be a very non-idiomatic use of Exceptions. Instead of being able to 
check `->getMessage()` or `->getCode()` to find out the cause, which is 
automatically supported by generic Exception-handling mechanisms as 
provided by every framework, one needs to specifically call a 
`->getResults()` methods to find out the individual results.

And when it's a generic function where depending on the type of item 
processed, one is also interested in the “return value” of the 
successful cases, instead of the binary success/failure option, it would 
become very unwieldy, requiring the use of a single-statement try-block 
to handle both the “all successful” and the “at least one failure” case, 
ending up in a “return value with extra steps” situation.

     try {
         $results = bulk_process($items);
         /* All successful. */
     } catch (BulkProcessingFailures $e) {
         $results = $e->getResults();
         /* At least one failed. */
     }

     foreach ($results as $item => $result) {
         if ($result instanceof SuccessResult) {
             echo "Created item ", $item, " with ID: ", $result->getId(), 
PHP_EOL;
         } else {
             echo "Failed to create item ", $item, PHP_EOL;
         }
     }

Best regards
Tim Düsterhus