Hi, Thanks for clarifying. Think the RFC would benefit from having
some of these examples in it. I also had in mind that it's handy for
catching many exceptions when logging stuff and re-throwing like:

}  catch (FirstException | SecondException ex) {
    logger.error(ex);
    throw ex;
}

Regards //Björn

PS Sorry for top-posting...

Den 2016-03-09 kl. 08:05, skrev Bronisław Białek:
Hi :)

I think it is feature that is useful time to time, not very often.
One example:

class PackingFailed extends \Exception implements PackagingException {}

// this exception could originate from package with assertions/exceptions,
// so I cannot use common interface with above
class EmptyName extends \Exception implements ValidationException {}

class Packer
{
     /** @throws PackingFailed */
     public function pack(PackTemplate $packTemplate) : Pack
     {
         try {
             return $this->save($packTemplate);
         } catch (IOException $e) {
             throw new PackingFailed('', 0, $e);
         }
     }
}

class PackTemplate
{
     /** @throws EmptyName */
     public function __construct(string $name)
     {
         if ($name === '') {
             throw new EmptyName();
         }
     }
}

/** @throws SomeException */
function packeForMe(string $name) : Pack
{
     try {
         return (new Packer())->pack(new PackTemplate($name));
     } catch (PackingFailed | ValidationException $e) {
         throw new SomeException($e); // or return null in other cases
     }
}


2016-03-09 2:47 GMT+01:00 Pierrick Charron <pierr...@adoy.net>:

Hi Björn,

The only time I had to do this with core PHP exceptions is to make the
code compatible for both PHP5 and PHP7:

try {
} catch(\Exceptions $e) {
} catch(\Throwable $e) {
}

But it will of course not be applicable since this feature is targeting
PHP7.1. Other than that the PHP core exception hierarchy is well enough for
MY needs. But if someone already had to do this fill free to provide your
use case as an example.

My main target is custom exceptions (even if the logic is applicable on
everything Throwable). A custom exception use case would be some method
that throw thwo different kind of exceptions like for example the doctrine
AbstractQuery::getSingleResult (NoResultException,
NonUniqueResultException) that you could want to handle the same way.

An other really easy example would be simple code like this one that I
found in symfony (not really a big deal but still)

} catch (AccessException $e) {
     return false;
} catch (UnexpectedTypeException $e) {
return false;
}

And other piece of code using multiple libraries.


On 8 March 2016 at 18:06, Björn Larsson <bjorn.x.lars...@telia.com> wrote:

Den 2016-03-08 kl. 22:42, skrev Pierrick Charron:

Hi internals,

Bronisław Białek and I would like to start a discussion about allowing
multiple exception types to be caught in a single catch statement.

https://wiki.php.net/rfc/multiple-catch

A working implementation and tests are available in the RFC.

We are waiting for your constructive feedback and thoughts.

Thanks
Pierrick

Nice RFC! Think it would be good if you had an example in the
RFC showing the applicability of catching two php exceptions.
Especially given the new exception hierarchy in PHP 7. I'm also
pondering if the main target for this is custom exceptions or
the built-in ones or both?

Regards //Björn Larsson

PS





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to