Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107659
Message-ID: <11C11DE1-9D3B-4CB1-8226-AD48A0CE7A33@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7FE32B78-49B1-47A6-B68F-55F7AD607C85"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 24 Oct 2019 11:38:41 -0400
In-Reply-To: <5f8115ce-0f89-c401-c8b8-9f865e76edd3@xs4all.nl>
Cc: PHP internals <internals@lists.php.net>
To: Dik Takken <d.takken@xs4all.nl>
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
 <5f8115ce-0f89-c401-c8b8-9f865e76edd3@xs4all.nl>
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_7FE32B78-49B1-47A6-B68F-55F7AD607C85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 24, 2019, at 8:05 AM, Dik Takken <d.takken@xs4all.nl> wrote:
> I fully agree. However I think the fear of having to add tons of try /
> catch to existing code is exaggerated. I use Python a lot, which=20
> quite an exception throwing machine in comparison. Still, my code is =
not
> cluttered with exception handling.
>=20
> So, converting a ton of warnings to exceptions in PHP does not worry =
me
> at all. I would welcome it, but not as a bulk operation. I agree that =
we
> need to ask the question for each case. I would still prefer the =
answers
> to bias towards exceptions though.

It is not a "fear" for some, where fear is something someone worries =
about that might be unfounded.=20

For me, at least, it is an annoyance I already have to deal with for =
those things that throw exception, such as DateTime and DateTimeZone. =20=


So not a fear but a preference not to make existing annoyances any worse =
than they already are.  #jmtcw

> Or maybe introduce a try() function that can wrap calls. Since most - =
ife
> not all - functions would throw a single type of exception, the
> following would catch that exception and return null in stead:
>=20
>  $x =3D try(fopen('missing.txt', 'r'))

Now that I could really get behind.

However, I might suggest it be handled slightly differently, based on my =
experience with Go (which IMO does not handle in a optimal way.)

Basically you want to be able to do something like this:

if ( $result =3D try( fopen( 'missing.txt', 'r' ), $handle ) ) {
    error_log( $result->getMessage() );
    return;
}
$contents =3D fread($handle, filesize($filename));
fclose($handle);

Effectively I think we want to be able to easily tell as an expression =
whether it succeeded for failed.  Try() could returns either the  =
exception, if thrown, or false (or null) if no exception was thrown.  =
The called function's return value would be returned by reference as the =
second parameter.

> 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.

I would want it to capture every exception. Why not?

-Mike=

--Apple-Mail=_7FE32B78-49B1-47A6-B68F-55F7AD607C85--