Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109208
User-Agent: Microsoft-MacOutlook/16.35.20030802
Date: Sun, 22 Mar 2020 19:39:34 +0100
To: Mike Schinkel <mike@newclarity.net>,
	Dan Ackroyd <Danack@basereality.com>
CC: PHP internals <internals@lists.php.net>
Message-ID: <77F0B565-E360-435A-9F56-03CE0545B48E@me.com>
Thread-Topic: [PHP-DEV] [RFC][DISCUSSION] throw expression
References: <5BEF8264-4003-4056-A31C-FF8BEE85FED6@me.com>
 <CA+kxMuREXT60g3UyNbXT=pfMFVcoWO+rco5Exft2Pj-vB_30Bw@mail.gmail.com>
 <D3934DF9-AEF9-48D7-B607-8BE4DB8F0806@newclarity.net>
In-Reply-To: <D3934DF9-AEF9-48D7-B607-8BE4DB8F0806@newclarity.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] throw expression
From: ilija.tovilo@me.com (Ilija Tovilo)

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 th=
e arrow function) to be valid PHP code
* Adding a throwException function will unnecessarily fragment your codebas=
e 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 throwi=
ng them. I personally don't think it's a good fit for PHP because PHP can't =
enforce you to handle these cases.

Regards

=EF=BB=BFOn 22.03.20, 19:14, "Mike Schinkel" <mike@newclarity.net> wrote:

    > On Mar 22, 2020, at 1:16 PM, Dan Ackroyd <Danack@basereality.com> wro=
te:
    >=20
    > On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo <ilija.tovilo@me.com> wrot=
e:
    >>=20
    >> Due to the modest feedback I=E2=80=99d like to move the throw expression R=
FC to =E2=80=9Cunder discussion=E2=80=9D.
    >>=20
    >> https://wiki.php.net/rfc/throw_expression
    >>=20
    >=20
    > Regarding the example:
    >=20
    > $condition || throw new Exception('$condition must be truthy')
    >  && $condition2 || throw new Exception('$condition2 must be truthy');
    >=20
    > The "Deprecate left-associative ternary operator"* RFC made it so tha=
t
    > parentheses are required when ternary operators are nested in
    > complicated statements.
    >=20
    > Would a similar requirement for parentheses around complicated throw
    > expressions be a suitable solution to avoid people being surprised by
    > the behaviour?
    >=20
   =20
    Why can't you just do this in userland code?
   =20
    function throwException(Exception $exception) {
    	throw $exception;
    }
   =20
    $callable =3D fn() =3D> throwException( new Exception() );
   =20
    // $value is non-nullable.
    $value =3D $nullableValue ?? throwException( new InvalidArgumentException=
() );=20
   =20
    // $value is truthy.
    $value =3D $falsableValue ?: throwException( new InvalidArgumentException=
() );
   =20
    // $value is only set if the array is not empty.
    $value =3D !empty($array)
        ? reset($array)
        : throwException( new InvalidArgumentException() );
   =20
   =20
    -Mike
    P.S. I am probably in the vast minority on this list but I would like t=
o see fewer places that throw exceptions, not more.=20
   =20
    I want to deal with errors where they happen, not throw exceptions or h=
ave to catch them as I have found that I can write much more robust and easi=
er to read code when I write without using exceptions. I came to this realiz=
ation because of learning that Go does not endorse exceptions and then I lea=
rned 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 tim=
e."
   =20
    I now have a whole slew of classes who only purpose is to wrap PHP func=
tions 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.
   =20
    One particularizing problematic exception in PHP is with the DataTime c=
lass. 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.