← Чи можна використовувати try/catch для управління логікою?
docs: English JsonRpcBundle docs, REST and MCP Bundle sections, package cards
uk/articles/from-tg/architecture/try-catch.md
новий файл +55
−0
1
+
# Чи можна використовувати try/catch для управління логікою?
2
+
3
+
:::info subtitle="Питання читача"
4
+
1. Чи можна використовувати try catch для управління логікою? Я досі використовував, але сьогодні натрапив на твердження, що це не є хороша практика.
5
+
2. Наскільки ресурсозатратне використання вкладених try catch? Прочитав, що сам try catch сам по собі "дешевий", а от throw вимагає багато ресурсів. Це так?
6
+
:::
7
+
8
+
## 1. Чи можна використовувати try/catch для управління логікою?
9
+
10
+
Так, можна, і це цілком робочий підхід. Питання тут не в "правильно/неправильно", а в тому, яка філософія тобі ближча і що підходить під конкретну архітектуру.
11
+
12
+
Насправді, це дуже холіварна тема.
13
+
14
+
Є табір, який каже *"винятки тільки для виняткових ситуацій"*, а є табір, який спокійно використовує їх як механізм flow control. І обидва підходи живуть собі нормально.
15
+
16
+
Я особисто вважаю, що це питання зручності, а не абсолютна істина. Мені зручніше обʼєктно-орієнтований підхід. ІМХО, якщо код читається краще — значить, підхід має право на життя.
17
+
18
+
Приклад:
19
+
20
+
```php
21
+
try {
22
+
$code = $repo->getByUrl($url);
23
+
} catch (NotFoundException) {
24
+
$code = $this->generateAndSave($url);
25
+
}
26
+
```
27
+
28
+
У такій ситуації це працює природно і зрозуміло: "немає? створи". Немає нічого поганого в тому, щоб ловити конкретний виняток і робити fallback-логіку.
29
+
30
+
Проблеми починаються тільки тоді, коли exception використовується замість звичайного if у найпростіших місцях, або коли репозиторій починає кидати винятки там, де очікувано повертати null. Але то вже питання дизайну коду.
31
+
32
+
## 2. Чи дійсно throw дорогий?
33
+
34
+
Так, це правда.
35
+
36
+
try/catch сам по собі майже нічого не коштує. Їх можна хоч вкладати — накладні витрати мізерні, але `throw` — дорогий, бо PHP генерує backtrace і створює повноцінний Exception-об’єкт, що виїдає процесор.
37
+
38
+
Тому:
39
+
40
+
- Якщо `throw` трапляється рідко — взагалі не проблема.
41
+
- Якщо "not found" стає нормальним шляхом виконання (часто), тоді варто задуматись, чи не простіше повертати null або Result-об’єкт — чисто з точки зору продуктивності.
42
+
43
+
Але й тут все залежить від контексту. Якщо навантаження невелике — різниця взагалі не має сенсу.
44
+
45
+
## Підсумую мою позицію
46
+
47
+
- Використовувати try/catch для логіки можна. Це не є поганою практикою само по собі, це питання смаку, стилю і команди.
48
+
- Якщо код читається краще — я завжди за.
49
+
- try/catch дешевий, throw дорожчий, але в реальних проєктах це рідко стає bottleneck’ом.
50
+
51
+
Якщо тобі це зручно і воно вписується в архітектуру — продовжуй використовувати.
52
+
53
+
---
54
+
55
+
*Вперше опубліковано в Telegram-каналі [«Створений щоб помирати»](https://t.me/php_while_true/88) 14.11.2025.*