Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109210 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37299 invoked from network); 22 Mar 2020 21:01:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Mar 2020 21:01:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C1C071801FD for ; Sun, 22 Mar 2020 12:25:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 22 Mar 2020 12:25:46 -0700 (PDT) Received: by mail-qk1-f176.google.com with SMTP id k13so1337836qki.2 for ; Sun, 22 Mar 2020 12:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KK5nhbg5iUtll9abdkbvD1sHN9Vu63IQTvaducYXYp4=; b=TU0sNvvQ55whyT0R2GQQGkQY4MYs+xBpOJxTJcVy1byQ9tqdYOwiA0TR+Ha3U+ujRU 9Q07xx4ntICraV0fvkHHoCHoWMXz84xGlhjen1I9DZmkqvVN5kjuSQ7XT7dHes+eLW3Y 4xjFcQ5OJ578kZaMoAHrfjeF4zDggWeZeoKehl0A3yiXeQbyo6M7RG+GHqK9CzePb5Yv o+zB3afdVM1Q9XchE9/tDqHbky0ZvQtuBR/JsW5+DBWRK0VCuNvl54lJykiHNrCnBJiH 3pEYyPX9BcNFVrrj5BPa5fJugaiplsuADkWWH62tKdanttFm94OkZt9L0buNlSuj7fzg mvWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KK5nhbg5iUtll9abdkbvD1sHN9Vu63IQTvaducYXYp4=; b=kirRkKv195szjWnZ0A20cT5AhJsKf0jguWQZdgRc6yIQDMMsCBoV9irStxXOUoJV3C HEzZZGjlxtE6ADua/ITyib2tbXM5lzvmB6EspzqpI9g7+7/+g64PozDdnp2c0RAntdCU jm0rBB1vHjFDvavhVjKSSJGKqwke4//dGbGXnmiVUT7njGypJ6zk2ll6wJlNxGaZztp5 FNdXekiSBg/1NCW401di+hlx/8N8yT7vXKTv9oY/TJdKClQX6qJFn6DSgm/fVNz5f0eA 5qpKy6wIdJqbr6y/rABW+NAvF9bsrofcR6zuDJlNbfkMK2WJ0WXNOWARPvBTyr9wEHwr JBTw== X-Gm-Message-State: ANhLgQ38AE8h13JQTKuWFnNI40+4Ei3ZC78M4mmSSdFC0x4u1j7g7U+u l5XGkZCkD6KO7FtoOyAwLJM7bQ== X-Google-Smtp-Source: ADFU+vvJcIWnaaex4t9y24XRO/tsbJEx7HYQMJLj/OCopZZfkvrJhQviGfqFy0hWfhqXQczBzYFOFg== X-Received: by 2002:a37:c43:: with SMTP id 64mr12963783qkm.47.1584905144630; Sun, 22 Mar 2020 12:25:44 -0700 (PDT) Received: from ?IPv6:2601:c0:c680:5cc0:b161:bce7:21ab:aa25? ([2601:c0:c680:5cc0:b161:bce7:21ab:aa25]) by smtp.gmail.com with ESMTPSA id r3sm9756425qkd.3.2020.03.22.12.25.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2020 12:25:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: <77F0B565-E360-435A-9F56-03CE0545B48E@me.com> Date: Sun, 22 Mar 2020 15:25:42 -0400 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <2760095A-3559-4EC9-B019-EA49CD708A8C@newclarity.net> References: <5BEF8264-4003-4056-A31C-FF8BEE85FED6@me.com> <77F0B565-E360-435A-9F56-03CE0545B48E@me.com> To: Ilija Tovilo X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC][DISCUSSION] throw expression From: mike@newclarity.net (Mike Schinkel) > On Mar 22, 2020, at 2:39 PM, Ilija Tovilo wrote: >=20 > Hi Mike >=20 > Thanks for your feedback! >=20 > 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: >=20 > * 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 >=20 > 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. >=20 > Regards Hi Ilija, I am fine if other people use exceptions as long as I have ways to not = have to use them.=20 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. =20 -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. >=20 > =EF=BB=BFOn 22.03.20, 19:14, "Mike Schinkel" = wrote: >=20 >> On Mar 22, 2020, at 1:16 PM, Dan Ackroyd = wrote: >>=20 >> On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo = wrote: >>>=20 >>> Due to the modest feedback I=E2=80=99d like to move the throw = expression RFC 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 = that >> 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 to see fewer places that throw exceptions, not more.=20 >=20 > 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." >=20 > 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. >=20 > 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. >=20 >=20