Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107618
Message-ID: <CAFBBA5C-9ACD-4A9B-9BD3-302DCDEA0AC7@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0319EF5A-29F5-4803-8929-87CD551E58BA"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 21 Oct 2019 17:10:27 -0400
In-Reply-To: <CAG9XoMQn8XD3ezpr9CupbHZS2pDFNbCW6wW4pCDv77=pgNhxzA@mail.gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
To: Benjamin Morel <benjamin.morel@gmail.com>
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
 <CAH0Uv3FfJ=6LN=whewRs0WswxLXN6TSRXWyUaNYCwYsTp81d9A@mail.gmail.com>
 <CAG9XoMRT=iMKuxDCJW=zWbzm10BFFoKMLVx3aVrUGYbzs1KdMg@mail.gmail.com>
 <6fa02cb5-b474-4b36-4e0f-89679475e250@gmail.com>
 <CAG9XoMQn8XD3ezpr9CupbHZS2pDFNbCW6wW4pCDv77=pgNhxzA@mail.gmail.com>
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_0319EF5A-29F5-4803-8929-87CD551E58BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Oct 21, 2019, at 4:38 PM, Benjamin Morel <benjamin.morel@gmail.com> =
wrote:
> Sure, you can do without exceptions. I think what you're suggesting is
> similar to Go's error handling.

Yes, it is like Go's error handling.=20

>  But PHP at some point decided in favour of
> exceptions, so it would be logical to pursue in that direction.

Must we? =20

Maybe it is time to (at least) consider alternate approaches? Not to =
deprecate Exceptions =E2=80=94 as many prefer to use them =E2=80=94 but =
as an alternative to Exceptions for those who would prefer to use error =
values instead?


> I would classify most, if not all, filesystem-related functions as =
mostly
> "yes, do stop execution by default when something fails". So this is, =
as
> well, in favour of exceptions.=20

Are you sure?  Could a file system function not just as easily "stop" =
and return an error value vs. throwing an exception?

> To take the mkdir() example, the only reasonable failure reason I can =
think
> of that would not justify throwing an exception, is when the directory
> already exists.
>=20
> So I would be OK with this:
>=20
> mkdir(): bool; // true if successful, false if the target directory =
already
> exists
>=20
> This is, IMO, the only time we can safely proceed while ignoring the
> outcome of the operation, as the filesystem is in the same state =
whether or
> not the function succeeded (the directory exists). All other outcomes =
are,
> IMO, exceptional situations, and throwing an exception is a safe way =
to
> guarantee that execution will *not* continue after such an error.

Why must it be a thrown exception vs. a returned error object? =20

For a given application that failure might not be exceptional; the app =
might have a fallback solution that want to use instead.

> Handling each and every error manually by using the return value =
requires a
> lot of discipline, which could be a very steep learning curve for PHP
> developers used to a fast prototyping language. And if people don't
> strictly follow the rules, you're opening the door to a whole lot =
potential
> bugs in codebases. And, you miss the ability of automatic error =
reporting
> for uncaught errors, that you get almost for free with exceptions and =
a
> single try/catch at the top level.

That is definitely a good argument to keep supporting Exceptions in PHP.

But not an argument to make Exceptions the only approach. I have been =
coding professionally for a really long long and =E2=80=94 until =
recently =E2=80=94 never felt like I was happy with how I was doing =
error handling, always thinking I would "get around to figuring out a =
better approach."=20

Then about a year ago I started using Go, and Go's approach to error =
handling just clicked for me. Go's philosophy is to handle the error as =
soon as you one is aware of it and to only ever handle it once.  Since I =
have been using that strategy I have become very happy with my error =
handling, and I now (attempt) to use the same strategy in my PHP code.=20=


In PHP I now typically wrap anything that can generate an exception in =
my own try_catch() function, and that function returns an error object I =
can then process if an except is thrown inside. But it is visually ugly =
and tedious to have to use that function all the time.

So what I am hoping for is that PHP recognizes there are two strategies =
for error handling =E2=80=94 1. Throwing exceptions vs. 2. Returning =
error values =E2=80=94 and that PHP 8.0 and behind will respect =
programmers and allow them to embrace the strategy they feel is best for =
their use-case.

-Mike=

--Apple-Mail=_0319EF5A-29F5-4803-8929-87CD551E58BA--