Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
References: <CAOfKkdQ_9jQw5p6hcCx=YL-RoZWf4st8Q=C9hknHUzR97P0fhA@mail.gmail.com>
 <alpine.DEB.2.20.1603091149080.3594@whisky.home.derickrethans.nl>
 <CAOfKkdRWv8Z4z1bWHFHnX_EK=wQ-vxryy24731qnFhu7MHxRkw@mail.gmail.com>
 <CADyq6s+F1BpV9iksypM9-UKHxPoR8TJMBjomZz6cXM0msN6Egg@mail.gmail.com> <CAOfKkdT3H+Y7MsnOU6pdRokwBfHPqbf2fVfqrBZZjU0i4qwJLQ@mail.gmail.com>
In-Reply-To: <CAOfKkdT3H+Y7MsnOU6pdRokwBfHPqbf2fVfqrBZZjU0i4qwJLQ@mail.gmail.com>
Date: Wed, 09 Mar 2016 13:27:44 +0000
Message-ID: <CAL0xaBG1Fv2XfgZr7H50KM-fC_XJtV1bcm=iYktnFrFC7XMe-w@mail.gmail.com>
To: Pierrick Charron <pierrick@adoy.net>, Marco Pivetta <ocramius@gmail.com>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	=?UTF-8?B?QnJvbmlzxYJhdyBCaWHFgmVr?= <after89@gmail.com>
Content-Type: multipart/alternative; boundary=089e0115fb8e4c411a052d9daacd
Subject: Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--089e0115fb8e4c411a052d9daacd
Content-Type: text/plain; charset=UTF-8

I'm definetly lately started to use instanceof to check the type of
exception I've got and throw further those that I don't need. This is
especially valuable for CLI applications (I have a few daemons in PHP).

So a big +1 on the proposal idea, as for the tech part -  maybe unions is a
good idea.

Arvids Godjuks.

On Wed, 9 Mar 2016, 15:24 Pierrick Charron, <pierrick@adoy.net> wrote:

> On 9 March 2016 at 08:08, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > On 9 March 2016 at 14:03, Pierrick Charron <pierrick@adoy.net> wrote:
> >
> >> Hi Derick
> >>
> >> I agree that most of the time the best solution is to implement a clean
> >> exception hierarchy but as stated in the RFC :
> >>
> >> "A solution to fix this problem on the user level would be to implement
> a
> >> common interface for ExceptionType1 and ExceptionType2 and catch it.
> >> However, this is only possible when you control the exception hierarchy
> in
> >> your own code, but not possible when you don't control the code."
> >>
> >
> > I understand the use-case, but I don't see it as a widespread scenario.
> In
> > most cases, I've been doing something like following:
> >
> >
> I agree that this the RFC will not get the oscar for feature of the year,
> but I think it will lead in those few use-case to more readable code.
>
>
> > public function stuff()
> > {
> >     try {
> >         $this->willFail();
> >     } catch (FirstException $e) {
> >         $this->handleFailure($e);
> >     } catch (SecondException $e) {
> >         $this->handleFailure($e);
> >     } catch (ThirdException $e) {
> >         $this->handleFailure($e);
> >     }
> > }
> >
> >
> The thing I don't like about this approach is that I have to read the code
> and double check to make sure that the catch statement call the same
> method.
> For the amount of work that needs to be done in the Engine (see the patch
> attached to the RFC) this is far more readable and it is clear that the
> code to handle those 3 exceptions is the exact same one. And if the code of
> handleFailure is small you can even put it at this single place.
>
> public function stuff()
> {
>     try {
>         $this->willFail();
>     } catch (FirstException | SecondException | ThirdException $e) {
>         $this->handleFailure($e);
>     }
> }
>
> Even then, this is a rare eventuality, and as pointed out above, usually
> > fixed when wrapping exceptions correctly, if you have control over the
> > exception types).
> > Seems way below the 80/20 use-case to me, and introduces syntax changes
> as
> > well.
> >
> > Cheers,
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
> >
>

--089e0115fb8e4c411a052d9daacd--