Re: [RFC][DISCUSSION] throw expression

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