Re: Reclassifying some PHP functions warning as exceptions

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