# Multicatch RFC proposal

- Thread: https://externals.io/message/89886
- Original archive: https://news-web.php.net/php.internals/89886
- Started by after89@gmail.com on 2015-12-24T22:40:29+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #89886 — after89@gmail.com — 2015-12-24T22:40:29+00:00

URL: https://externals.io/message/89886#89886

Hello everyone!

I've just created an RFC draft for catching multiple exception types
in one catch statement:
https://github.com/bronek89/php-multicatch-rfc

I wrote RFC on github to check if there is any positive response from community.

Basically it introduces possibility to write code such as:

try {
    // ...
} catch (DbException | ResourceNotFoundException $e) {
    throw new HttpException("not found", 404, $e);
} catch (\Throwable $e) {
    throw new HttpException("fail", 500, $e);
}

Provided patch is my first experience with PHP source code, so it
could be not perfectly written (or simply poor ;-) ) .

What do you think about introducing that kind of feature into PHP?

-- 
Regards,
Bronisław Białek.

---

## #89887 — Sara Golemon — 2015-12-24T23:08:51+00:00

URL: https://externals.io/message/89886#89887 · In reply to: #89886

> I've just created an RFC draft for catching multiple exception types
> in one catch statement:
> https://github.com/bronek89/php-multicatch-rfc
>
> I wrote RFC on github to check if there is any positive response from community.
>
> Basically it introduces possibility to write code such as:
>
> try {
>     // ...
> } catch (DbException | ResourceNotFoundException $e) {
>     throw new HttpException("not found", 404, $e);
> } catch (\Throwable $e) {
>     throw new HttpException("fail", 500, $e);
> }
>
> Provided patch is my first experience with PHP source code, so it
> could be not perfectly written (or simply poor ;-) ) .
>
> What do you think about introducing that kind of feature into PHP?
>
I think introducing union types should be a prerequisite for this as
we don't want the much more widely impactful feature of arg/return
type hinting to be constrained by syntax we choose here (and making
them inconsistent would be even worse).

That said, from a general principle point of view, it certainly
doesn't seem unreasonable.  In an own-codebase one would probably use
interfaces, have each exception implement the the common denominator
(INotFound or what-have-you), but in a world of foreign components
that's not always practical.

On the other hand, one could just catch a throwable and use a pattern like this:

} catch (\Throwable $e) {
  switch (true) {
    case ($e instanceof DbException):
    case ($e instanceof ResourceNotFoundException):
      throw new HttpException("not found", 404, $e);
    default:
      throw new HttpException("fail", 500, $e);
  }
}

So I'm not personally going to get super excited about it, even if I
would vote in favor.

-Sara

---

## #89911 — Dan Ackroyd — 2015-12-28T18:47:22+00:00

URL: https://externals.io/message/89886#89911 · In reply to: #89886

> Hello everyone!
>
> I've just created an RFC draft for catching multiple exception types
> in one catch statement:
> https://github.com/bronek89/php-multicatch-rfc
>
> I wrote RFC on github to check if there is any positive response from community.
>
> Basically it introduces possibility to write code such as:
>
> try {
>     // ...
> } catch (DbException | ResourceNotFoundException $e) {
>     throw new HttpException("not found", 404, $e);
> } catch (\Throwable $e) {
>     throw new HttpException("fail", 500, $e);
> }
>
> Provided patch is my first experience with PHP source code, so it
> could be not perfectly written (or simply poor ;-) ) .
>
> What do you think about introducing that kind of feature into PHP?
>

Yes, please. The alternative work-arounds are not as good.

Though I also am concerned about it getting in the way of other
proposals, I don't think it would be an issue. The meaning of the
syntax in your example is pretty obvious. So the only way it could be
a problem is if another RFC proposed a different and 'not as obvious'
meaning.

cheers
Dan