Уведомления об ошибках мешают работать. Вчера было двенадцать, сегодня уже двадцать. Есть радикальный способ улучшить ситуацию: поймать исключение, ничего не записать и вернуть положительный ответ.
График ошибок падает до нуля. Можно показать руководителю. Желательно раньше, чем руководитель попробует оформить заказ.
Пользователю приятнее видеть галочку
Возьмём условную форму заявки. Человек заполнил поля, нажал кнопку. База в этот момент недоступна. Обработчик ловит всё подряд и отвечает: «Спасибо, заявка принята».
С точки зрения интерфейса всё великолепно: никаких пугающих сообщений, переход на красивую страницу. С точки зрения человека заявка существует. С точки зрения базы — нет.
Мне здесь страшнее всего ложное решение, которое мы предложили пользователю принять. Он больше не будет пробовать. Не сохранит введённый текст. Не позвонит, потому что уверен: с ним свяжутся. Мы обменяли понятный сбой на незаметную потерю.
Успех в ответе — обещание о состоянии операции. Его нельзя выбирать только потому, что зелёный цвет приятнее красного.
Запиши «что-то пошло не так»
Допустим, мы всё-таки добавили лог. Теперь в нём пятьсот одинаковых строк. Без номера операции, без этапа, без связи с запросом. Информация формально есть. Пользоваться ею примерно так же удобно, как искать свой чемодан по описанию «был с ручкой».
Для расследования нужны идентификатор операции и контекст перехода: что пытались сделать, на каком шаге остановились. При этом пароли, токены и полные чувствительные данные в лог не отправляются. Диагностика не требует складировать всё, до чего удалось дотянуться.
Ещё полезно различать ожидаемый отказ и поломку. Неверный адрес в форме — повод объяснить человеку, что поправить. Недоступная база — повод сообщить о сбое и разобраться с сервисом. Одинаковое «успешно» в обоих случаях не делает интерфейс проще.
А если можно продолжить?
Можно. Например, заказ сохранён, а отправка необязательной аналитики не удалась. Ломать покупку из-за аналитики было бы странно. Но здесь мы осознанно отделили важную операцию от побочного действия и сохранили правду об обоих.
То же касается асинхронного процесса: сообщение «принято в обработку» уместно, если работа действительно надёжно принята. Оно не означает, что результат уже готов. Человек должен понимать, какое состояние ему показывают.
Я за спокойный интерфейс. Ошибку можно объяснить без стека вызовов и паники. Но спокойствие заканчивается там, где приложение начинает врать о выполненной работе.
Хорошая обработка исключения оставляет систему в понятном состоянии. Если после неё никто не знает, существует ли заказ, исключение обработали только для статистики.
