> On Oct 24, 2019, at 8:50 AM, Dik Takken <d.tak...@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:
>
> $filepath = __DIR__ . '/foobar.json';
> if (false === ($content = file_get_contents($filepath)) ) {
> error_log( sprintf("failed to open '%s'", $filepath ));
> return false;
> }
>
> becomes:
>
> $content = file_get_contents($filepath)
>
> 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.
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.
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
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>
