Шаблон кодуLaravel

Laravel throw_if() / throw_unless(): винятки без зайвого if

Як замінити простий if + throw на throw_if() або throw_unless(), вибрати форму без подвійного заперечення, передати клас винятку з параметрами та будувати читабельні захисні перевірки.

Захисна перевірка часто має дуже простий зміст: якщо умова порушена, виконання не повинно йти далі. У звичайному PHP це природно записується через if і throw.

Коли така перевірка займає лише один простий блок, Laravel дозволяє зробити намір ще помітнішим через throw_if() або throw_unless().

Замість простого if + throw

До

php

if (! $user->isActive()) {    throw new DomainException(        'User must be active.',    );}

Після

php

throw_unless(    $user->isActive(),    DomainException::class,    'User must be active.',);

Обидва варіанти зупиняють виконання, якщо користувач неактивний. Але throw_unless() читається як коротке правило: продовжуй лише тоді, коли користувач активний.

Це найбільш корисно на початку методу, де кілька захисних перевірок визначають, чи можна взагалі переходити до основної логіки.

throw_if() і throw_unless() описують умову з різних боків

PHP - Вибирайте форму, яка читається природно

throw_if(    $order->isCancelled(),    DomainException::class,    'Cancelled order cannot be processed.',); throw_unless(    $user->isActive(),    DomainException::class,    'User must be active.',);

Не вибирайте helper механічно. throw_if() добре читається з негативним станом на кшталт isCancelled(), а throw_unless() - з позитивним інваріантом на кшталт isActive(). Уникайте подвійних заперечень.

Можна передати клас винятку та аргументи його конструктора

PHP - Клас винятку з параметрами конструктора

final class InactiveUserException extends DomainException{    public function __construct(int $userId)    {        parent::__construct(            "User {$userId} must be active.",        );    }} throw_unless(    $user->isActive(),    InactiveUserException::class,    $user->id,);

Другий аргумент може бути назвою класу винятку. Якщо умова вимагає кинути виняток, Laravel створить цей клас і передасть наступні аргументи в його конструктор.

Це добре працює з предметними винятками, де назва класу пояснює причину зупинки краще за загальний RuntimeException.

Helper також приймає готовий виняток або звичайний текст

PHP - Готовий виняток або RuntimeException з текстом

throw_if(    $order->isLocked(),    new LogicException('Order is locked.'),); throw_if(    $quantity < 1,    'Quantity must be greater than zero.',);

Можна передати вже створений об'єкт винятку. Якщо другим аргументом є звичайний текст, Laravel створить RuntimeException з цим повідомленням.

Для бізнес-правил окремий клас винятку часто дає кращий контракт, а короткий текст зручний для локальних технічних перевірок.

Кілька незалежних правил добре читаються як послідовність захисних перевірок

PHP - Послідовні захисні перевірки

throw_unless(    $user->isActive(),    InactiveUserException::class,    $user->id,); throw_if(    $order->isCancelled(),    OrderCancelledException::class,    $order->id,); throw_unless(    $order->canBeProcessed(),    OrderCannotBeProcessedException::class,    $order->id,

Основна логіка залишається внизу без додаткових рівнів вкладеності. Кожен рядок перед нею відповідає на одне питання: яка умова повинна виконуватися, щоб метод міг продовжити роботу.

Такий стиль особливо зручний, коли перевірки незалежні одна від одної і кожна має власний виняток.

Складну умову краще спочатку назвати

До

php

throw_unless(    $user->isActive()        && ! $order->isCancelled()        && (            $order->belongsTo($user)            || $user->isAdmin()        ),    DomainException::class,    'Order cannot be processed.',);

Після

php

$canProcessOrder =    $user->isActive()    && ! $order->isCancelled()    && (        $order->belongsTo($user)        || $user->isAdmin()    ); throw_unless(    $canProcessOrder,    DomainException::class,    'Order cannot be processed.',);

throw_if() і throw_unless() не роблять складну умову автоматично зрозумілою. Якщо вираз уже важко прочитати, дайте йому назву або винесіть правило в окремий метод.

Також ці helper-функції не є заміною для всіх інших механізмів Laravel. Для перевірки вхідних даних краще використовувати validation, для правил доступу - policies або gates, а для простого HTTP status response можуть бути доречні abort_if() та abort_unless().

Це скорочення синтаксису, а не нова модель обробки помилок

throw_if() і throw_unless() не створюють транзакцію, не звітують про виняток окремим способом і не перетворюють його на HTTP-відповідь самі по собі. Вони лише перевіряють умову та кидають вказаний виняток.

Коли звичайний if + throw кращий

коли перед винятком треба виконати кілька дій;
коли умова має складне пояснення і окремий блок робить код зрозумілішим;
коли є else або кілька різних гілок поведінки;
коли перевірка містить важливий контекст, який губиться в одному рядку;
коли звичайний if для команди читається природніше за незнайому helper-функцію.

Сила throw_if() і throw_unless() не в мінімальній кількості рядків. Вони корисні тоді, коли проста захисна перевірка починає читатися як правило: якщо цей стан заборонений - зупинись; якщо цей інваріант не виконується - зупинись.

#laravel-12 #laravel-13 #php-8-4 #php-8-5 #error-handling #throw-if #throw-unless #guard-clauses

Замість простого if + throw

throw_if() і throw_unless() описують умову з різних боків

Можна передати клас винятку та аргументи його конструктора

Helper також приймає готовий виняток або звичайний текст

Кілька незалежних правил добре читаються як послідовність захисних перевірок

Складну умову краще спочатку назвати

Це скорочення синтаксису, а не нова модель обробки помилок

Коли звичайний if + throw кращий

Схожі поради