On 21-10-19 19:56, Mike Schinkel wrote:
> The idea that functions that I could previously dealt with in four lines of 
> code:
> $filepath = __DIR__ . '/foobar.json';
> if (false === ($content = file_get_contents($filepath)) ) {
>    error_log( sprintf("failed to open '%s'", $filepath ));
>    return false;
> }
> Will potentially now requires me to add a second brace-enclosed block and two 
> more lines of code and force me to handle varying exception classes causes me 
> to cringe and will make me want to cry:
> 
> $filepath = __DIR__ . '/foobar.json';
> try {
>    $content = file_get_contents( $filepath );
> } catch (Exception $exception) {
>    error_log( sprintf( "failed to open '%s'", $filepath ) );
>    return false;
> }
> 

Indeed, surrounding the function call with try / catch is what you need
to do when you want to retain the old behavior and convert the exception
into a return value that indicates an error.

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.

> Since I know that many in the PHP world believe that exceptions are a good 
> thing, I understand that I will be unlikely to change everyone's mind and get 
> them to start doing error handling as soon as they discover the error rather 
> than just throw it and let some other code that doesn't have as much context 
> deal with it.  
> 
> But my hope is at least PHP won't change to force having to use try/catch for 
> practically every function call. Such a change might even be enough to 
> finally get me to give up on PHP and move full time to Go because it will 
> make coding in PHP so tedious.

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. 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:

* Just let it crash (which is the right thing to do in some cases)
* Have a caller higher up in the call stack handle it
* Surround the function call with a try / catch later, should we decide
that we want to handle the problem locally anyway.

> Just the other day I had to deal with the fact PhpStorm flags functions that 
> return Exceptions if I don't handle them, and `new DateTime()` throws an 
> Exception because it's optional parameter could cause a failure, even though 
> I was not passing in any parameter. I had to wrap in my own `TryCatch()` 
> function that basically just buries the Exception to get PhpStorm to stop 
> complaining.

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. You don't get that when a function returns false or
null in case of error. When you get the code inspection warning, you can
either:

* Handle the exception
* Pass the exception to the caller and add a @throws to the doc string
* Suppress the inspection by using the following inspection hint:

 /* @noinspection PhpUnhandledExceptionInspection */

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.

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to