Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104497
MIME-Version: 1.0
References: <CAKg-N=XODDd=eU=E8cXG=uKayn5AETNH_FLnOCWOVXPM-PWkqg@mail.gmail.com>
 <bbbc5b31-69c7-744c-1174-7d62d5e0e226@gmail.com>
In-Reply-To: <bbbc5b31-69c7-744c-1174-7d62d5e0e226@gmail.com>
Date: Thu, 21 Feb 2019 21:00:41 +0100
Message-ID: <CAKg-N=WE12us2jW2rAzmmqBS815fu2QLzeg6bFKas3wLxFpx1g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008043ab05826cee36"
Subject: Re: [PHP-DEV] Optional catch binding
From: franssen.roland@gmail.com (Roland Franssen)

--0000000000008043ab05826cee36
Content-Type: text/plain; charset="UTF-8"

> it produces a warning - and it should, since what is being done is what
usually should not be done

I didn't want to turn this into an "error handling best practices"
discussion. Exceptions might not be recommended to use for flow-control,
yet this is possible today and really depends on the exception type itself
and it's fallback handling:

try {
  $o = $container->get('id');
} catch (ServiceNotFoundException) {
  $o = $container->get('other_id');
}

Leaving out the $e variable makes the lack of error handler more explicit.

Roland,

Op do 21 feb. 2019 om 20:35 schreef Stanislav Malyshev <smalyshev@gmail.com
>:

> Hi!
>
> > Allthough global exception catching might not be a good practice per se,
> I
> > don't see a real reason to forbid it. However, these are 2 independent
> > features that can be voted for I guess.
>
> It's not forbidden now. But there's no reason to encourage it and
> develop a dedicated syntax for it. Current syntax works just fine. Yes,
> it produces a warning - and it should, since what is being done is what
> usually should not be done - ignoring exceptions.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>

--0000000000008043ab05826cee36--