Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107666
Message-ID: <AA25339E-E8FD-4E03-9185-295A7B6F5AEF@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A8234463-1315-4A72-8671-C7D669A79534"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 24 Oct 2019 15:17:11 -0400
In-Reply-To: <47e3fd4c-94ce-6b89-9a88-1b49ec21da0b@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>
 <1451C117-D656-472D-9FD0-642351300BD9@newclarity.net>
 <47e3fd4c-94ce-6b89-9a88-1b49ec21da0b@xs4all.nl>
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_A8234463-1315-4A72-8671-C7D669A79534
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 24, 2019, at 8:50 AM, Dik Takken <d.takken@xs4all.nl> wrote:
> However, you could also choose to leverage the new behavior of =
throwing
> exceptions to simplify your code. Passing the error condition to the
> caller can now be done by *not* handling the exception that is thrown, =
so:
>=20
>  $filepath =3D __DIR__ . '/foobar.json';
>  if (false =3D=3D=3D ($content =3D file_get_contents($filepath)) ) {
>     error_log( sprintf("failed to open '%s'", $filepath ));
>     return false;
>  }
>=20
> becomes:
>=20
>  $content =3D file_get_contents($filepath)
>=20
> Here we assume that the exception contains an appropriate message
> allowing us to omit generating it manually. Of course, the caller will
> have to be adjusted to handle the exception in stead of the false. An
> IDE like PHPStorm will nicely point you at the places in your code =
that
> need to be adjusted.

Of course you can program that way, but you eventually have to deal with =
the error, and if you don't handle it where it happens then you know =
less about the context than if you just go ahead and handle it were the =
error first occurred.

This is not just my opinion, but the opinion of numerous others[1-6] =
(yes, I have recently shared these links twice before.)


> One could also reason the other way around. When a function returns =
some
> value or false in case of an error you have to check the return value
> for practically every function call.=20


Note the I am not arguing people should be required to handle errors, =
only that I (and others like me) are empowered if we want to
to handle the errors without having to try{]catch{} lots of exceptions.  =
And your try() "function" was a good way to empower us to do that.

> And we all forget to do so,
> resulting in unexpected failures. Exceptions allow us to simply use =
the
> return value without additional checks. Should anything go wrong =
calling
> the function we have plenty of options:

That assumes the developer is going to be sloppy.  Admittedly most =
developer are sloppy, myself included at times.

But I want to be able to get rid of the training wheels and be allowed =
to build robust software if I choose to do so.

> You do not have to use a wrapper. Yes, PHPStorm nicely points you at a
> possible failure point in your code, which reminds you to think about
> how to handle them.

Yes, unfortunately I know that.  :-(

Let's say that the function that I am calling is 10 levels deep in the =
function call tree.  Now I have to either have a try{}catch{} for =
everything that can throw an exception, or a @throw PHPDoc a the top of =
each function. But if I do the latter now I have to do the same in the =
9th level.  And if I add @throw at the 9th level now I have to document =
at the 8th level too. And so on and so on all the way up to level 2.

So basically with Exceptions in PhpStorm I am forced to me deal with the =
exception either with a try{}catch{} OR I have to do it at every level =
of my code.  And it is possible to disable those warnings, but I WANT =
those warning so I don't miss an exception. I just want a way not to =
have most functions return exceptions.

So it would be much easier to just handle it once locally without the =
try{}catch{}. And if PHP were to introduce a standard error object, say =
PHP\Error, then PhpStorm could flag them as not being handled for every =
function that potentially returns one.

> You don't get that when a function returns false or
> null in case of error.=20

True, but that is not what your try() "function" idea would do, as =
described above.  It would/should return either the exception object, or =
maybe better a new PHP\Error type, or SplError type.

> Since exceptions should mostly be used for situations where it is best
> to run for the emergency exit, wrapping a function call in a try / =
catch
> is not expected to be something done frequently.

The problem with that is the code throwing the exception makes the =
decision it is "exceptional" on behalf of the app/website, but it is =
really the app/websites responsibility to decide it is truly exceptional =
from the perspective of the app/website. It is very possible the=20
app/website has a fallback for a scenario that someone who implemented a =
core PHP function believed was exceptional.

Basically, I am just asking to be put in control related to =
errors/exceptions instead of having to work around decisions other =
people made for me.

-Mike

[1] http://www.lighterra.com/papers/exceptionsharmful/ =
<http://www.lighterra.com/papers/exceptionsharmful/>
[2] https://sidburn.github.io/blog/2016/03/25/exceptions-are-evil =
<https://sidburn.github.io/blog/2016/03/25/exceptions-are-evil>
[3] http://xahlee.info/comp/why_i_hate_exceptions.html =
<http://xahlee.info/comp/why_i_hate_exceptions.html>
[4] https://www.joelonsoftware.com/2003/10/13/13/ =
<https://www.joelonsoftware.com/2003/10/13/13/>
[5] https://mortoray.com/2012/04/02/everything-wrong-with-exceptions/ =
<https://mortoray.com/2012/04/02/everything-wrong-with-exceptions/>
[6] https://www.atlassian.com/blog/archives/exceptions_are_bad =
<https://www.atlassian.com/blog/archives/exceptions_are_bad>




--Apple-Mail=_A8234463-1315-4A72-8671-C7D669A79534--