Обробка помилок у коді: щоб нічого не падало мовчки

Що таке обробка помилок простими словами

Уяви, що вдома прорвало трубу. Далі - два сценарії.

Перший: десь під підлогою тихо капає вода. Ні звуку, ні сигналу. Ти живеш спокійно місяць - а потім знаходиш згнилу підлогу та потоп у сусідів знизу. Аварія була. А ти дізнався останнім.

Другий: труба дала течу - і одразу заволав датчик, перекрився кран, на телефон прилетіло сповіщення. Неприємно? Ще б пак. Але ти полагодив усе за годину, поки проблема була розміром із калюжку.

Ось це і є обробка помилок. Програма завжди десь ламається - це так само неминуче, як дощ. Питання одне: ти дізнаєшся про це одразу та по-людськи - чи потім і катастрофою?

Чому вайбкодеру важливо обробляти помилки

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

Не задаси агенту правила про помилки - він за замовчуванням обере найнебезпечніше. Сховає їх. Зовні все працює, а всередині тихо капає.

• Користувач бачить білий екран або вічну крутилку - і йде мовчки. Навіть не напише тобі.
• Ти не розумієш, що зламалося: помилка ніде не лишила сліду.
• Один крихітний збій валить весь застосунок - хоча міг би лишитися локальною дрібницею.

Різниця між «у мене сайт іноді глючить, не знаю чому» і «я бачу кожну проблему в логах і лагоджу за хвилину» - це і є культура обробки помилок. Хороша новина: правила прості. Один раз вшив у промпт - і забув.

Пʼять правил доброї обробки помилок

У скілі з обробки помилок є пʼять залізних принципів. Розберемо кожен на пальцях.

1. Падай швидко й гучно

Найшкідливіше - це ковтати помилку Ковтати помилку (swallow) - спіймати збій і нічого з ним не зробити: ні показати, ні записати, ні передати далі. Програма вдає, що все добре, хоча це не так. . Зламалося - значить, має сплисти прямо там, де сталося. А не бути закопано глибше «щоб нікого не лякати».

Звучить банально. Але саме тут новачки (та ліниві агенти) лажають найчастіше: ставлять блок ловлі помилки - і лишають його порожнім. Це як заклеїти миготливу лампочку «check engine» ізострічкою. Лампочка не миготить - значить, усе добре, так? Так-так.

2. Людині - одне повідомлення, тобі - інше

На одну й ту саму помилку потрібні два різних тексти:

• Людині - коротко й ввічливо: «Щось пішло не так, спробуй пізніше». Без технічних подробиць, без страшних слів, без шматків коду на екрані.
• Тобі в лог - усі подробиці: що саме впало, де і з якими даними. Це твій датчик протікання.

3. У помилки має бути імʼя, а не просто текст

Погана помилка - це голий рядок "щось зламалося". По ньому не зрозуміти геть нічого.

Хороша помилка - типізована Типізована помилка - помилка не як випадковий рядок тексту, а як обʼєкт зі зрозумілою назвою та кодом: наприклад NotFound (не знайдено), Unauthorized (немає доступу), RateLimited (надто часто). За кодом одразу ясно, що сталося і як реагувати. : у неї є код і зрозуміле імʼя. Дивись:

• NotFound - запитаного немає.
• Unauthorized - треба ввійти в акаунт.
• ValidationError - людина ввела щось не те.
• RateLimited - надто багато запитів поспіль, час пригальмувати.

Коли помилки іменовані, застосунок точно знає, що показати людині та яку відповідь повернути. «Не знайдено» - це зовсім не те саме, що «немає доступу» чи «наш сервер приліг».

4. Повторюй запит з розумом, а не лобом у стіну

Іноді помилка тимчасова: інтернет блимнув, сервіс на секунду підвис. Тут доречний повтор зі зростаючою паузою Повтор зі зростаючою паузою (retry with backoff) - якщо запит не пройшов, спробувати ще раз, але не одразу, а через паузу, яка з кожною спробою збільшується. Так ти не завалюєш сервер чергою однакових запитів. : спробував ще разок, не вийшло - почекав трохи довше, і так кілька разів.

Але повторювати можна далеко не все:

5. Помилка - частина договору з тим, хто користується кодом

Уміє застосунок повернути помилку «немає доступу» чи «надто багато запитів» - хай робить це в одному зрозумілому форматі щоразу. Тоді й фронтенд, і ти сам, і майбутній агент завжди знають, чого чекати. Хаотичні, різні на вигляд помилки - це друге джерело болю одразу після мовчазних.

Приклад із життя: форма, яка мовчки втрачала заявки

Ти зібрав з агентом форму зворотного звʼязку на сайті. Потицяв - працює. Виклав. За тиждень помічаєш: заявок нуль. Хоча лічильник запевняє, що форму відкривали десятки людей.

Що сталося насправді:

1. У сервісу надсилання листів скінчився ліміт - він почав повертати помилку.
2. Агент за замовчуванням обгорнув надсилання в блок ловлі помилки і лишив його порожнім.
3. Тому людина бачила бадьоре «Дякуємо, заявку надіслано!» - а лист нікуди не летів. Тихо капало під підлогою цілий тиждень.

Як застрахуватися з самого старту? Просто видай агенту правила. Ось готовий промпт:

Коли пишеш будь-який код, який може зламатися (запити в мережу, робота з базою, надсилання листів, введення користувача), дотримуйся правил:


Ніколи не лишай порожній блок обробки помилки. Кожен такий блок має або коректно обробити збій, або передати його далі, або записати в лог.


На кожну помилку роби два повідомлення. Користувачу - коротке й ввічливе, без технічних деталей. У лог - повну інформацію: що впало, де і з якими даними.


Не показуй користувачу успіх, поки дія реально не виконалася. Якщо лист не пішов - скажи чесно, що не вийшло, і запропонуй повторити.


Використовуй зрозумілі типи помилок з кодом: не знайдено, немає доступу, неправильне введення, надто багато запитів, внутрішня помилка.


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

У кінці покажи мені список місць, де код може впасти, і як ти в кожному з них обробляєш помилку.

Здорова та хвора обробка помилок: порівняння

Чек-лист: чи мовчить твій застосунок про помилки

Перш ніж викочувати щось людям, прожени по чек-листу:

1. Що побачить людина, якщо це зламається? Відповідь «білий екран» чи «не знаю» - погано.
2. Де я побачу, що це зламалося? Якщо ніде - додай лог.
3. Чи немає порожніх блоків обробки помилок? Попроси агента показати всі місця ловлі помилки і що в них відбувається.
4. Чи не показую я успіх раніше часу? «Надіслано» має зʼявлятися лише після реального надсилання.
5. Чи не витекли секрети в логи? Паролям, токенам і ключам у логах не місце.

Часті помилки новачка в обробці помилок

• Лишати блок ловлі помилки порожнім. Найнебезпечніша звичка на світі. Помилка зникає, проблема росте в темряві.
• Показувати людині технічний текст. Стектрейс на екрані лякає звичайних людей і допомагає зловмисникам. Їм - ввічливе повідомлення, тобі - лог.
• Брехати про успіх. «Готово!» до того, як дія реально сталася, - пряма дорога до втрачених заявок і замовлень.
• Повторювати те, що повтором не лагодиться. Неправильний пароль чи «не знайдено» сто разів поспіль - марнування сил і навантаження на сервер.
• Нескінченні повтори без ліміту. Добʼєш чужий сервіс, а заодно підвісиш і свій застосунок.
• Логувати секрети. Спокусливо записати «весь запит цілком», але туди часто прилітають паролі й ключі. Вичищай чутливе.