[RFC] Optional Catch Block Body

Of course, empty catch blocks are bad practice in most cases. But this particular proposal is not intended to encourage these bad practices. I'm just suggesting that you don't have to write an extra boiler plate at the syntax level in situations where it's necessary.

From what I can tell, it's very rare to have empty catch blocks, and
even more being done rightfully. I'd be very suspicious if I came
across such code.

I think the extra boilerplate is actually a good thing, showing the
explicit intent to not catch the error. I get that the proposal is not
intended to encourage such a thing, but I agree with Ayesh: it would
definitely will.

Interesting catch, but i have been thinking of a better approach of
catching errors without the try and catch block madness.

Here is my suggestion:

try (Exception $e) {
  // define logic
}

if ($e) {
  // execute code...
}

looks way more clean and structured, what do y'all think?

Just a suggestion though.

Hi, Rob!

Good point! I also know one another case when empty catch block are useful.

When we want to avoid returning null values, we resort to using exceptions
so that the client code can somehow handle the absence of values.
For example:

if ($user->getName() !== null) {
$this->doSomethingWithUserName($user->getName());
}

We usually add an exception inside such getters if there is no value:

try {
$this->doSomethingWithUserName($user->getName());
} catch (UserNameIsNull);

This is useful when we need to "do nothing" when there is no value. In my
opinion, this code looks more declarative.

We can do something like this also with repositories:

try {
$post = $this->postRepository->get($postId);

// do something with post
} catch (PostNotFound);

But again, there is a fine line between situations where an empty body of
a catch block is reasonable and when it is not.

чт, 31 июл. 2025 г. в 12:13, Rob Landers rob@bottled.codes:

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

Hi, Rob!

When we want to avoid returning null values, we resort to using exceptions
so that the client code can somehow handle the absence of values.
For example:

if ($user->getName() !== null) {
$this->doSomethingWithUserName($user->getName());
}

We usually add an exception inside such getters if there is no value:

try {
$this->doSomethingWithUserName($user->getName());
} catch (UserNameIsNull);

There will be TypeError because "doSomethingWithUserName" should accept
strings.
Using exceptions to check types is rough practice because exceptions aren't
cheap. "if" is cheaper.

This is useful when we need to "do nothing" when there is no value. In my
opinion, this code looks more declarative.

We can do something like this also with repositories:

try {
$post = $this->postRepository->get($postId);

// do something with post
} catch (PostNotFound);

Instead of idents inside another block I'd prefer to use early returns:

try {
-- ...
-- ...
-- ...
-- ...
-- ...
} catch (...)

vs

try {
-- ...
} catch (...) {
-- return
}
...
...
...
...

Or even "if"

if (!...) {
-- return ...
}
...
...
...
...

--
Best regards,
Dmitrii Derepko.
@xepozz

Am 31.07.2025 um 09:10 schrieb Rob Landers rob@bottled.codes:

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).

I'm not 100% sure I understood your examples but this smells like you are using exceptions for flow (or maybe state?) control which I'm not sure I would encourage.

Regards,

• Chris

It's explicitely to jump/unwind the stack -- PHP has no other way (other than suspending a fiber or yielding a generator) to jump/unwind the stack to a given point. Fibers are the superior way here, but even then, throwing from the fiber is still the best way to terminate it and force a GC of the stack there. This is basically using it as a longjmp (in C terms) which PHP doesn't have any other way to express. They're not used for flow control, or state. They merely force PHP to unwind the stack to a known place (all possible side-effects have already been done and it is either throw -- or wait for an external event, potentially forever -- which consumes memory and a thread).

— Rob

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:

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:

$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".

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".

As I say, readability is always subjective, but I would just see ";" vs
"{}" as a style choice, no obvious difference in intention. If anything,
it would risk me misreading the code, because I'd be looking for the
braces and not finding them.

A similar argument was made for keeping "var" as an alias of "public",
to indicate ... something; I argued against that reasoning at the
time: https://externals.io/message/91618#91634

I don't think the language needs to allow multiple ways of writing
everything, just so that projects can have subtle conventions of when to
use which one.

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.

If the aim is to make the intention explicit, we need some syntax that
makes the intention explicit, not just different punctuation we hope
will become established as a convention.

$foo = try $this->doSomething() ignore (Foo, Bar);

I think an inline syntax like this would be a powerful feature, and a
potential replacement for the @ operator:

$fh = null;
$fh = try fopen($filePath, 'w') ignore (FileLockedException);

One challenge would be optimising it so that the exception didn't build
a full stack trace then immediately discard it - this was touched on in
Larry's thread a while back https://externals.io/message/127188

--
Rowan Tommins
[IMSoP]

Hey Mihail

Am 06.08.25 um 13:34 schrieb Mihail Liahimov:

Hi!

At the moment, I can suggest this syntax:

try {
// do something
} catch (SomeIgnorableException) finally {
// do something
}

I find that ... challenging

When reading the code I now have to go to the end of the line to
understand that the second

// do something

does not belong to the try but to the finally...

And

try {
// break stuff
} catch (SomeIgnorableException)
finally {
// do something regardless
}

seems boken due to the missing }

But well....

We just have to adapt to something like this:

try {
// break stuff
}
catch (SomeIgnorableException)
catch (Some OtherIgnorableException)
finally {
// do something regardless
}

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+