Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.43 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>
In-Reply-To: <CADyq6s+F1BpV9iksypM9-UKHxPoR8TJMBjomZz6cXM0msN6Egg@mail.gmail.com>
Date: Tue, 15 Mar 2016 16:23:45 +0000
Message-ID: <CACwt+JcO601UDQA1LG_UsJVM7sxWXPdcfjgREvUi5YzRLBBczQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>, Pierrick Charron <pierrick@adoy.net>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	=?UTF-8?B?QnJvbmlzxYJhdyBCaWHFgmVr?= <after89@gmail.com>
Content-Type: multipart/alternative; boundary=001a11415a78d8a143052e18d263
Subject: Re: [PHP-DEV] [RFC Discussion] Catching multiple exception types
From: patrickallaert@php.net (Patrick ALLAERT)

--001a11415a78d8a143052e18d263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Le mer. 9 mars 2016 =C3=A0 14:08, Marco Pivetta <ocramius@gmail.com> a =C3=
=A9crit :

> 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. I=
n
> most cases, I've been doing something like following:
>
> public function stuff()
> {
>     try {
>         $this->willFail();
>     } catch (FirstException $e) {
>         $this->handleFailure($e);
>     } catch (SecondException $e) {
>         $this->handleFailure($e);
>     } catch (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 a=
s
> well.


+1

I will add to this that Exceptions must remain... exceptional! Too much
projects relies already on tens or hundreds of business exception while
those are mostly common "error" conditions that are better handled with
dedicated API calls.

To me, it doesn't look like a reasonable change when we consider the number
of tools/IDE to adapt compared to the possible usage of it.

Cheers,
Patrick

--001a11415a78d8a143052e18d263--