Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107667
Message-ID: <2A2E0ECF-7831-4221-B8A8-855251336761@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C333B9B0-7348-44E3-8624-3ACE3E7FA911"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 24 Oct 2019 15:42:49 -0400
In-Reply-To: <CALKiJKpjyyeph1aGys6tT_VfkvW1tOnYuP5ZJtKio5XqsaP8tA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Rowan Tommins <rowan.collins@gmail.com>
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
 <5f8115ce-0f89-c401-c8b8-9f865e76edd3@xs4all.nl>
 <11C11DE1-9D3B-4CB1-8226-AD48A0CE7A33@newclarity.net>
 <CALKiJKpjyyeph1aGys6tT_VfkvW1tOnYuP5ZJtKio5XqsaP8tA@mail.gmail.com>
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_C333B9B0-7348-44E3-8624-3ACE3E7FA911
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 24, 2019, at 12:31 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On Thu, 24 Oct 2019 at 16:38, Mike Schinkel <mike@newclarity.net> =
wrote:
>=20
>>> Here, try() would swallow only FileException, other exceptions are =
still
>>> thrown. I'm not sure if this construct is worth introducing though, =
the
>>> difference compared to a proper try / catch is much smaller.
>>=20
>> I would want it to capture every exception. Why not?
>=20
> Because you might want to convert =
"FileLockedByAnotherProcessException" to
> a locally-handled error, but allow "ServerIsOnFireException" to bubble =
up
> to a higher-level exception handler.  That's why catch blocks =
basically
> force you to specify class/interface names: you should catch only the
> exceptions you actually know how to handle in that particular piece of =
code.


I totally understand that, for those wanting to program with exceptions.=20=


But if we added a try() "function", the goal of that function IMO would =
be to capture all exceptions and return them as errors for those who =
don't want to use exceptions.  But I could just as easily has logic that =
says "if it is ServerOnException exception, I can throw it again" If I =
want too. Or I can handle it another way.

The point it, I am asking to be put 100% in control and be able to =
choose how to handle errors, not have to figure out which exceptions =
somethings throws because a function can throw many different types and =
those types are not always well documented.If it it is returned, I will =
always get it, even if my code did not expect it.

-Mike=

--Apple-Mail=_C333B9B0-7348-44E3-8624-3ACE3E7FA911--