Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128335
Precedence: bulk
MIME-Version: 1.0
References: <CAJWOiuN8fuejkX1Tj0h=s_Fs2bGEtz-qdMZxRTC1s4at23y=Vw@mail.gmail.com>
 <095f25f5-695b-46d4-9f31-5d7e7a04ce05@rwec.co.uk> <CANS-=peEKJRT0nZeCQPLah-rg0pDd1F1JecvAj95ya0MP8JNPg@mail.gmail.com>
In-Reply-To: <CANS-=peEKJRT0nZeCQPLah-rg0pDd1F1JecvAj95ya0MP8JNPg@mail.gmail.com>
Date: Thu, 31 Jul 2025 12:11:43 +0300
Message-ID: <CAGBsUrccP6+Enq_2wJ4XAajTRQmJTZLGPRW-5p4Wr5=B=kiC3Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Optional Catch Block Body
To: Lynn <kjarli@gmail.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000081fe2b063b360809"
From: tekiela246@gmail.com (Kamil Tekiela)

--00000000000081fe2b063b360809
Content-Type: text/plain; charset="UTF-8"

On Thu 31 Jul 2025, 11:32 Lynn, <kjarli@gmail.com> wrote:

>
> When I read `catch (Foo);` I read the intention of it being on purpose,
> whereas `catch (Foo) {}` I can easily interpret as "the developer forgot to
> handle the error" or "I can't tell if this is a bug or not". This often
> requires something like:
> ```php
> try {
>     // ...
> } catch (Foo) {
>     // do nothing
> }
> ```
>

I much more prefer the long version and I'd rather see this in my code than
just a semicolon or empty braces. If the developer must leave the catch
block empty they better have a pretty good reason and they should clearly
explain that in the code comment.

Now the boilerplate has increased from {} vs ; to quite some extra, just to
> ensure the intention. I don't know if omitting the body for this is the
> solution, or if there's something else we can do like: `ignore(Foo, Bar)`.
> When I read the code I want the intention to be clear, and an empty body
> just makes me doubt whether or not it is intended and/or correct. I do
> agree that empty catches are usually a sign of trouble, but realistically
> speaking we don't always have control over the situation due to legacy or
> vendor code.
>
> Just tossing some ideas out here:
> ```php
> $foo = try $this->doSomething() ignore (Foo, Bar);
>
> ignore(Foo, Bar) {
>     $foo = $this->doSomething();
> } catch (Throwable) {
>     // ....
> } finally {
>     // ...
> }
>
> try ignore(Foo, Bar) {
>     $foo = $this->doSomething();
> } catch (Throwable) {
>     // ...
> } finally {
>     // ...
> }
> ```
>

I read that as catch all exceptions apart from these which should bubble up
to the next exception handler. It could be useful in its own too.

I would vote NO to the proposal of short syntax for empty catch, not only
because it's bad practice but also because it's one of the places where
being very explicit is a good thing. An empty catch should be an eyesore
and have a mandatory comment. It's akin to a door with a sign "don't open"
versus a sign with "don't open, angry lions inside".

>

--00000000000081fe2b063b360809
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Thu 31 Jul 2025, 11:32 Lynn, =
&lt;<a href=3D"mailto:kjarli@gmail.com">kjarli@gmail.com</a>&gt; wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div><br></div><div>When I read `catch (Foo);` I read the intention of it=
 being on purpose, whereas `catch (Foo) {}` I can easily interpret as &quot=
;the developer forgot to handle the error&quot; or &quot;I can&#39;t tell i=
f this is a bug or not&quot;. This often requires something like:</div><div=
>```php</div><div>try {</div><div>=C2=A0 =C2=A0 // ...</div><div>} catch (F=
oo) {</div><div>=C2=A0 =C2=A0 // do nothing</div><div>}</div><div>```</div>=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I much more prefer the long version and I&#39;d rather see this i=
n my code than just a semicolon or empty braces. If the developer must leav=
e the catch block empty they better have a pretty good reason and they shou=
ld clearly explain that in the code comment.=C2=A0</div><div dir=3D"auto"><=
br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><div>Now the boilerplate has increased from {} vs ; to quite some extra, j=
ust to ensure the intention. I don&#39;t know if omitting the body for this=
 is the solution, or if there&#39;s something else we can do like: `ignore(=
Foo, Bar)`. When I read the code I want the intention to be clear, and an e=
mpty body just makes me doubt whether or not it is intended and/or correct.=
 I do agree that empty catches are usually a sign of trouble, but realistic=
ally speaking we don&#39;t always have control over the situation due to le=
gacy or vendor code.</div><div><br></div><div>Just tossing some ideas out h=
ere:</div><div>```php</div><div>$foo =3D try $this-&gt;doSomething() ignore=
 (Foo, Bar);</div><div><br></div><div>ignore(Foo, Bar) {</div><div>=C2=A0 =
=C2=A0 $foo =3D $this-&gt;doSomething();</div><div>} catch (Throwable) {</d=
iv><div>=C2=A0 =C2=A0 // ....</div><div>} finally {<div><div></div><div>=C2=
=A0 =C2=A0 // ...</div></div><div>}</div></div><div><br></div><div>try igno=
re(Foo, Bar) {</div><div>=C2=A0 =C2=A0 $foo =3D $this-&gt;doSomething();</d=
iv><div>} catch (Throwable) {</div><div>=C2=A0 =C2=A0 // ...</div><div>} fi=
nally {</div><div><div></div><div>=C2=A0 =C2=A0 // ...</div></div><div>}</d=
iv><div>```</div></div></div></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">I read that as catch all exceptions apart from the=
se which should bubble up to the next exception handler. It could be useful=
 in its own too.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
 would vote NO to the proposal of short syntax for empty catch, not only be=
cause it&#39;s bad practice but also because it&#39;s one of the places whe=
re being very explicit is a good thing. An empty catch should be an eyesore=
 and have a mandatory comment. It&#39;s akin to a door with a sign &quot;do=
n&#39;t open&quot; versus a sign with &quot;don&#39;t open, angry lions ins=
ide&quot;.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quo=
te_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--00000000000081fe2b063b360809--