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" <m...@newclarity.net> wrote:
> On Mar 22, 2020, at 1:16 PM, Dan Ackroyd <dan...@basereality.com> wrote:
>
> On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo <ilija.tov...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
