On Thu, Jul 31, 2025, at 06:53, Mihail Liahimov wrote:
> Introduction
>
> Currently, PHP requires a block body for catch clauses even when the caught
> exception is not used. This results in unnecessary boilerplate code. This RFC
> proposes allowing catch clauses without a body when the exception variable is
> omitted.
>
> Proposal
>
> Allow the following syntax where the curly braces can be omitted when no
> exception variable is specified and no handling is needed:
>
> try {
> // code that may throw
> } catch (SomeError);
>
> This would be equivalent to:
>
> try {
> // code that may throw
> } catch (SomeError) {}
>
> Motivation
>
> 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.
>
> Backward Incompatible Changes
>
> None. This is purely an additive change to the syntax.
I can see something like this being useful in niche applications. For example,
I have a proxy generation class that creates something like this:
public function remoteCall() {
$this->operation = nameof($this->remoteCall(...));
$this->arguments = func_get_args();
throw new SpecialException();
}
This SpecialException gets caught to let me know the application has consumed
the one-use proxy. Using it looks something like
rpc(fn(RemoteObject $o) => $o->remoteCall());
which just provides type-safe rpc at the expense of some boilerplate.
I also use empty exceptions to "jump" the stack when my framework knows there
is nothing more to do until outside events happen. I think I could probably use
fibers to do the same, but if the user is using a fiber library; there is no
guarantee they'll play nice together. This is true with exceptions as well, but
the user has direct control over exceptions (do not catch Throwable, for
instance).
That being said, I'm doing niche things. Outside of this framework/SDK, I have
not ever really used empty catches, and even in my case, my empty catches have
lengthy comments describing why they are empty in case a user steps into it, so
they can better understand how the framework works.
— Rob
