β Can you use try/catch to control logic?
docs: English JsonRpcBundle docs, REST and MCP Bundle sections, package cards
en/articles/from-tg/architecture/try-catch.md
new file +55
β0
1
+
# Can you use try/catch to control logic?
2
+
3
+
:::info subtitle="A reader's question"
4
+
1. Can you use try catch to control logic? I've been using it so far, but today I came across a claim that it's not a good practice.
5
+
2. How resource-intensive are nested try catch blocks? I read that try catch itself is "cheap", but throw requires a lot of resources. Is that true?
6
+
:::
7
+
8
+
## 1. Can you use try/catch to control logic?
9
+
10
+
Yes, you can, and it's a perfectly workable approach. The question here isn't "right/wrong", but which philosophy is closer to you and what fits a particular architecture.
11
+
12
+
In fact, it's a very holy-war topic.
13
+
14
+
There's a camp that says *"exceptions are only for exceptional situations"*, and there's a camp that calmly uses them as a flow control mechanism. And both approaches get along just fine.
15
+
16
+
Personally, I think it's a matter of convenience, not an absolute truth. The object-oriented approach is more convenient for me. IMHO, if code reads better, the approach has a right to exist.
17
+
18
+
An example:
19
+
20
+
```php
21
+
try {
22
+
$code = $repo->getByUrl($url);
23
+
} catch (NotFoundException) {
24
+
$code = $this->generateAndSave($url);
25
+
}
26
+
```
27
+
28
+
In this situation it works naturally and clearly: "not there? create it". There's nothing wrong with catching a specific exception and doing fallback logic.
29
+
30
+
Problems start only when an exception is used instead of a plain if in the simplest places, or when a repository starts throwing exceptions where returning null is expected. But that's a question of code design.
31
+
32
+
## 2. Is throw really expensive?
33
+
34
+
Yes, that's true.
35
+
36
+
try/catch by itself costs almost nothing. You can even nest them β the overhead is negligible, but `throw` is expensive, because PHP generates a backtrace and creates a full-fledged Exception object, which eats CPU.
37
+
38
+
So:
39
+
40
+
- If `throw` happens rarely β it's not a problem at all.
41
+
- If "not found" becomes a normal execution path (often), then it's worth considering whether it's simpler to return null or a Result object β purely from a performance standpoint.
42
+
43
+
But even here everything depends on the context. If the load is small, the difference doesn't matter at all.
44
+
45
+
## To sum up my position
46
+
47
+
- You can use try/catch for logic. It's not a bad practice in itself, it's a matter of taste, style and team.
48
+
- If code reads better, I'm always for it.
49
+
- try/catch is cheap, throw is more expensive, but in real projects it rarely becomes a bottleneck.
50
+
51
+
If it's convenient for you and fits the architecture, keep using it.
52
+
53
+
---
54
+
55
+
*First published in Ukrainian in the Telegram channel [βCreated to dieβ](https://t.me/php_while_true/88) on November 14, 2025.*