Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <D4.60.41796.FB75CB55@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 01 Aug 2015 00:23:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
References: <E6.64.22108.E69F7B55@pb1.pair.com> <55BBD019.5030106@stephencoakley.com> <55BC201D.6010600@malkusch.de>
In-Reply-To: <55BC201D.6010600@malkusch.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Throwable::addSuppressed()
From: me@stephencoakley.com (Stephen Coakley)

On 07/31/2015 08:25 PM, Markus Malkusch wrote:
> Stephen Coakley:
>
>> Interesting thought, but how is this different than including a previous
>> throwable and throwing a new, more descriptive exception?
>>
>> } catch (Exception $e1) {
>>       try {
>>           $resource->close();
>>       } catch (ResourceException $e2) {
>>           // Pass in $e2 as the previous exception in the chain.
>>           throw new ResourceFailedException($e1->getMessage(),
>> $e1->getCode(), $e2);
>>       }
>> }
>
> Sorry, in my previous mail I actually forgot to answer your question.
> What you suggest is a common pattern to work around the lack of
> Throwable::addSupressed(). There are two big differences:
>
> 1) There's no causality between e1 and e2. You pass the message from e1
> to the newly created ResourceFailedException which is caused by e2.
> Actually the causality here is correct, as ResourceFailedException is
> caused by e2. But what I understand is that ResourceFailedException
> should substitute e1 and e1 is not caused by e2. Just imagine e1 has the
> message "insufficient funds". Then the user gets an exception which says
> "insufficient funds" is caused by "could not rollback transaction".
>
> 2) You are loosing one stack trace (in this case from e1). For me the
> stack trace is the most important information in the exception. In this
> use case there are two stack traces and I want to have both of them.
>
> And then again this is just a simple example scenario with one resource.
> There might exist n resources.
>
> Markus Malkusch
>

That makes sense -- I can see the uses for that. I don't mean to play 
devil's advocate, but is it worth sacrificing the immutability of 
exceptions for an addSupressed() method? Other than that, I think I 
would be for such an addition.

-- 
Stephen Coakley