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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
