Re: [RFC][DISCUSSION] throw expression

> On Mar 22, 2020, at 2:39 PM, Ilija Tovilo <ilija.tovilo@me.com> wrote: > > Hi Mike > > Thanks for your feedback! > > Your solution works well and it's true that PHP would do just fine without accepting this > RFC. > However I do think this RFC makes sense for a few reasons: > > * I think that most people would expect some of the examples (especially the arrow function) to > be valid PHP code > * Adding a throwException function will unnecessarily fragment your codebase into throw > statements and calls to that function > * It's not as static analysis friendly > * The patch has very low complexity > > I agree that some languages do well with returning errors instead of throwing them. I > personally don't think it's a good fit for PHP because PHP can't enforce you to > handle these cases. > > Regards Hi Ilija, I am fine if other people use exceptions as long as I have ways to not have to use them. The lack of enforcement is not a concern for me, that is what code review is for. However if error handling vs exception handling were elevated to a standardized alternate strategy by PHP then static analysis could catch lack of handling said errors. In the case of allowing people to throw exceptions in expressions that just means for me that I have more code I have to wrap to avoid having to deal with those exceptions throughout my code if and when I use other people's code from Packagist or GitHub. -Mike P.S. However, I think my opinion on exceptions in PHP is in the minority, mine is only one opinion, and I don't even have a vote so I am not sure it matters what my preference is on this topic. > > On 22.03.20, 19:14, "Mike Schinkel" <mike@newclarity.net> wrote: > >> On Mar 22, 2020, at 1:16 PM, Dan Ackroyd <Danack@basereality.com> wrote: >> >> On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo <ilija.tovilo@me.com> wrote: >>> >>> Due to the modest feedback I’d like to move the throw expression RFC to “under >>> discussion”. >>> >>> https://wiki.php.net/rfc/throw_expression >>> >> >> Regarding the example: >> >> $condition || throw new Exception('$condition must be truthy') >> && $condition2 || throw new Exception('$condition2 must be truthy'); >> >> The "Deprecate left-associative ternary operator"* RFC made it so that >> parentheses are required when ternary operators are nested in >> complicated statements. >> >> Would a similar requirement for parentheses around complicated throw >> expressions be a suitable solution to avoid people being surprised by >> the behaviour? >> > > Why can't you just do this in userland code? > > function throwException(Exception $exception) { > throw $exception; > } > > $callable = fn() => throwException( new Exception() ); > > // $value is non-nullable. > $value = $nullableValue ?? throwException( new InvalidArgumentException() ); > > // $value is truthy. > $value = $falsableValue ?: throwException( new InvalidArgumentException() ); > > // $value is only set if the array is not empty. > $value = !empty($array) > ? reset($array) > : throwException( new InvalidArgumentException() ); > > > -Mike > P.S. I am probably in the vast minority on this list but I would like to see fewer places > that throw exceptions, not more. > > I want to deal with errors where they happen, not throw exceptions or have to catch them as > I have found that I can write much more robust and easier to read code when I write without using > exceptions. I came to this realization because of learning that Go does not endorse exceptions and > then I learned why they do not which strongly resonated with me. After that, I finally felt > comfortable saying that "Exceptions seemed like a good idea at the time." > > I now have a whole slew of classes who only purpose is to wrap PHP functions and classes > that throw exceptions so I can call them w/o having to use try{}catch{}. Instead I use an if() > afterwards to check and then handle it if there was an error. > > One particularizing problematic exception in PHP is with the DataTime class. I have found it > effectively impossible to create a class that extends DateTime without having the potential for an > exception to be thrown (unless someone knows a way that I do not?) The potential is actually > hypothetical, but PhpStorm nonetheless still complains that I have not handled exceptions when using > that child class. > >