I agree with the distinction described by Nikita. There are definitely cases where a special return value is still the best option.
In addition I would say in some cases it can be useful to have both versions available: One that returns FALSE or NULL, another that throws an exception. This is for cases where it is up to the calling code whether a failure is considered "exceptional" or not, or whether the calling code wants to check the error in place or have it bubble up the call stack. Whether something is exceptional can be a matter of expectation, and previous knowledge within the calling code. Take e.g. the reflection API: - If we call "new ReflectionClass(self::class)", we assume that the class exists. If it does not, this would warrant a runtime exception. - If we already checked "class_exists($class)" before, then it makes sense for "new ReflectionClass($class)" to throw an exception. We would even want a runtime exception. - If we receive an arbitrary string that matches a class name regex, we would like to have a ReflectionClass::createOrNull($class), which would NOT throw an exception, but return NULL if the class does not exist. If we provide two variations, they should definitely live in different functions / methods, instead of e.g. having a parameter to determine the failure behavior. Having two separate methods/functions allows better code verification by the IDE, and avoids false inspection warnings for "unhandled exception". Considering the BC impact, I think that providing an alternative method/function will be the best we can do in most cases. -- Andreas On Mon, 21 Oct 2019 at 18:03, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > Hi David, > > Firstly, I agree with Nikita's general rule of which Warnings should be > promoted and which need deeper thought. > > I would like to challenge one assertion in your e-mail, which is related to > that thought process: > > > On Mon, 21 Oct 2019 at 14:52, David Negrier <d.negr...@thecodingmachine.com> > wrote: > > > We would be happy to promote more warnings to exceptions as those: > > - are more predictable > > - can be more easily caught / handled > > > > > I have always thought, and continue to think, that converting all Warnings > (and Notices) to Exceptions is inappropriate, because Exceptions have some > very specific behaviours, which are not always desirable: > > - They immediately jump control out of the current frame of execution. > Unless you put a separate "try-catch" around every line, there is no > "acknowledge and run next line". > - Their default behaviour if not handled is to completely terminate > whatever is happening, right up to showing a blank white screen. > > There is no general way to know whether the result of aborting execution > completely is better or worse than carrying on with unexpected values. In a > program that's not expecting it, either one could lead to data loss or > corruption. > > There are definitely places where a Warning can reasonably be converted to > an Exception; but I don't think this should be done as some kind of bulk > change. Each Warning we promote should have at least one person answer the > question "is it likely that terminating processing when this happens at > run-time will be better than flagging a Warning and returning a defined > value?" > > Regards, > -- > Rowan Tommins > [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
