Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128333
Precedence: bulk
MIME-Version: 1.0
References: <CAJWOiuN8fuejkX1Tj0h=s_Fs2bGEtz-qdMZxRTC1s4at23y=Vw@mail.gmail.com>
 <095f25f5-695b-46d4-9f31-5d7e7a04ce05@rwec.co.uk>
In-Reply-To: <095f25f5-695b-46d4-9f31-5d7e7a04ce05@rwec.co.uk>
Date: Thu, 31 Jul 2025 10:31:54 +0200
Message-ID: <CANS-=peEKJRT0nZeCQPLah-rg0pDd1F1JecvAj95ya0MP8JNPg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Optional Catch Block Body
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d59d23063b357a88"
From: kjarli@gmail.com (Lynn)

--000000000000d59d23063b357a88
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2025 at 10:11=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.php@r=
wec.co.uk>
wrote:

> On 31/07/2025 05:53, Mihail Liahimov wrote:
> > Reduced Boilerplate: Eliminates unnecessary empty blocks when
> > exceptions only need to be caught and ignored.
> > Improved Readability: Makes the code more concise and focuses on the
> > important parts.
>
>
> The "boilerplate" in question is a single saved byte - ";" instead of
> "{}". Depending on keyboard layout one or the other might be slightly
> easier to type. Readability is always subjective, but I think most PHP
> programmers would quite easily read "{}" as "do nothing".
>
> I suspect the real motivation here is that *coding standards* require
> more boilerplate than the language in this case, such as a newline
> between the opening and closing brace.
>
> But PHP is not Python, where whitespace is enforced by the compiler; nor
> is it Go, where a coding standard is part of the standard library; so
> this is not the right place to change coding standards. Even if we add
> the short-hand syntax, there is nothing to stop those coding standards
> forbidding its use.
>
> As others have said, good uses of empty catch blocks are rare -
> generally, you want to at least log that the exception happened, and
> where it was caught. And even those which are functionally empty often
> benefit from a comment explaining why they're not doing anything, which
> sits naturally between the braces.
>
> If for some reason your project is commonly using completely empty catch
> blocks, you can document where and why "catch(Foo){}" is allowed in your
> local coding standard.
>
>
> --
> Rowan Tommins
> [IMSoP]
>

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
}
```
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 =3D try $this->doSomething() ignore (Foo, Bar);

ignore(Foo, Bar) {
    $foo =3D $this->doSomething();
} catch (Throwable) {
    // ....
} finally {
    // ...
}

try ignore(Foo, Bar) {
    $foo =3D $this->doSomething();
} catch (Throwable) {
    // ...
} finally {
    // ...
}
```

--000000000000d59d23063b357a88
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 31,=
 2025 at 10:11=E2=80=AFAM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop=
.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On 31/07/2025 05:53, Mihail Liahimov w=
rote:<br>
&gt; Reduced Boilerplate: Eliminates unnecessary empty blocks when <br>
&gt; exceptions only need to be caught and ignored.<br>
&gt; Improved Readability: Makes the code more concise and focuses on the <=
br>
&gt; important parts.<br>
<br>
<br>
The &quot;boilerplate&quot; in question is a single saved byte - &quot;;&qu=
ot; instead of <br>
&quot;{}&quot;. Depending on keyboard layout one or the other might be slig=
htly <br>
easier to type. Readability is always subjective, but I think most PHP <br>
programmers would quite easily read &quot;{}&quot; as &quot;do nothing&quot=
;.<br>
<br>
I suspect the real motivation here is that *coding standards* require <br>
more boilerplate than the language in this case, such as a newline <br>
between the opening and closing brace.<br>
<br>
But PHP is not Python, where whitespace is enforced by the compiler; nor <b=
r>
is it Go, where a coding standard is part of the standard library; so <br>
this is not the right place to change coding standards. Even if we add <br>
the short-hand syntax, there is nothing to stop those coding standards <br>
forbidding its use.<br>
<br>
As others have said, good uses of empty catch blocks are rare - <br>
generally, you want to at least log that the exception happened, and <br>
where it was caught. And even those which are functionally empty often <br>
benefit from a comment explaining why they&#39;re not doing anything, which=
 <br>
sits naturally between the braces.<br>
<br>
If for some reason your project is commonly using completely empty catch <b=
r>
blocks, you can document where and why &quot;catch(Foo){}&quot; is allowed =
in your <br>
local coding standard.<br>
<br>
<br>
-- <br>
Rowan Tommins<br>
[IMSoP]<br></blockquote><div><br></div><div>When I read `catch (Foo);` I re=
ad the intention of it being on purpose, whereas `catch (Foo) {}` I can eas=
ily interpret as &quot;the developer forgot to handle the error&quot; or &q=
uot;I can&#39;t tell if this is a bug or not&quot;. This often requires som=
ething like:</div><div>```php</div><div>try {</div><div>=C2=A0 =C2=A0 // ..=
.</div><div>} catch (Foo) {</div><div>=C2=A0 =C2=A0 // do nothing</div><div=
>}</div><div>```</div><div>Now the boilerplate has increased from {} vs ; t=
o quite some extra, just to ensure the intention. I don&#39;t know if omitt=
ing 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 empty body just makes me doubt whether or not it is int=
ended and/or correct. I do agree that empty catches are usually a sign of t=
rouble, but realistically speaking we don&#39;t always have control over th=
e situation due to legacy or vendor code.</div><div><br></div><div>Just tos=
sing some ideas out here:</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>} ca=
tch (Throwable) {</div><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 ignore(Foo, Bar) {</div><div>=C2=A0 =C2=A0 $foo =3D $this-&=
gt;doSomething();</div><div>} catch (Throwable) {</div><div>=C2=A0 =C2=A0 /=
/ ...</div><div>} finally {</div><div><div></div><div>=C2=A0 =C2=A0 // ...<=
/div></div><div>}</div><div>```</div></div></div>

--000000000000d59d23063b357a88--