Comments 10
Поэтому следование этому принципу порождает «дома с привидениями» — вроде работает, но вдруг пятницу 31-го чётного года падает — и не понятно почему (реальный случай!). И хрен докопаешься без целого квеста с тупиками и разветвлениями.
Так что «по-умолчанию» всё же препочтительнее fail safe (естественно с записями в лог, предупреждениями и т.п. — иначе это будет ignore) — именно так, например, работает javascript в браузерах. Падает, но оставляет следы в логе.
Я резюмировал из статьи так: На проде fail safe, до прода - fail fast. С моим опытом вполне согласуется.
Так что — особенно для небольших команд — у меня правило: пишем сразу как в прод («сразу пишем хорошо» :) ). Иначе в прод отправляется «прототип» как он есть.
Да, в мобильных приложениях это очень весело, когда приложение внезапно молча закрывается.
На этапе разработки, падение приложения, конечно, предпочтительнее. Тестировщик сразу лезет в логи и заводит багу на разработчика. В этом и смысл fail-fast! В продакшене же, конечно, приложение не должно упасть. Оно должно собрать все данные об ошибке, отправить их куда надо, а пользователю вывести сообщение, что данная фича сейчас недоступна. Короче говоря, fail-safe! - это fail-fast! + бизнес-обёртка для минимизации ущерба.
Почему же, fail-fast! - это, в первую очередь, о системе, которая останавливает свою работу при возникновении ошибки, с прекращением всякой бизнес-логики. И не более. Обработка ошибки с последующим логированием стектрейса, возвращением негативного HTTP-статуса и прочей фиксацией ошибки могут быть заложены при прекращении бизнес-логики на системном уровне (тот самый случай "громкого падения"). При этом, бизнес-логика при негативном сценарии не осуществляется.
Принцип же fail-safe! подразумевает именно бизнес-логику при негативном сценарии. В этом и их различие.
Приведу пример. Клиент стучится на сервер за данными и не получает их. При реализации fail-fast! на экране пользователя возникает сообщение об ошибке, что-то вроде "HTTP Status 500: java.util.NoSuchElementException: Document not found..." и так далее. При этом, приложение упало как можно громче, с логами, аварийными записями в базу и так далее - но оно именно упало и больше ничего. Пользователь видит сообщение, морщится, но ничего, стерпит.
В случае же применения fail-safe! произойдёт такое же громкое падение с логами и прочим, но на клиент будет возвращено сообщение: "Спокойно, нет поводов для паники, мы не можем отыскать сервер, но обязательно его отыщем! Приходите завтра." Во втором случае, в негативный сценарий заложена дополнительная бизнес-логика, которая призвана сгладить пользователю негативный эффект.
А так, конечно, Вы правы - приложение должно падать как можно громче, причём, всегда.
В эру кубернетиса и облаков надо как можно быстрее упасть чтобы соседи перехватили знамя и понесли дальше. Я бы даже советовал выделять ресурсов по-минимуму чтобы при малейшем признаке фатала приложение завершалось и кубернетис перестартовал всё что можно.
Для клиентских приложений конечно можно и похромать какое-то время, чисто чтобы юзер сохранил данные. Но сколько осталось тех клиентских? Даже фотошоп в облаке.
Не кубером единым жив мир.
Согласитесь, потеря документа, над которым вы работаете на локальном компьютере - это плохо.
Да даже проще: у вас из-за ошибки разметки на любой странице или в скрипте шустро рестартует браузер в состоянии "с чистого листа" или хотя бы как он был при последнем ручном закрытии (ну, сохраняем конфиг не постоянно, а по фиксированному событию).
Для клиентских приложений конечно можно и похромать какое-то время, чисто чтобы юзер сохранил данные.
И сохранить сломанные данные, чтобы при загрузке этого битого файла упасть окончательно?
Не всё так однозначно (с)
Хм.
А как быть с таким вот случаем:
Подключились к серверу через сокет
Послали запрос. Все ок.
Получили ответ. Тоже все ок.
Шлем следующий.
Оп. Нам в лицо не удалось получить ответ за установленный таймаут.
Ошибка? Ну да. Падаем? В большинстве реальных случаев - можем попытаться еще раз переподключиться. Ну или сообщить об этом и предложить пользователю решать, что дальше делать.
О. Или вообще. Мы сервер. К нам подключились. Все нормально, начали сессию. Вот, пробуем читать - у клиента вырубили свет, мы получили 10054. Чего делать? Паниковать и падать? Или просто обработать это, закрыть сессию и обслуживать других клиентов?
Ну. Просто я не знаю. Если на каждую ошибку падать - как-то не очень круто это будет.
Я конечно не за то, чтобы втихую продолжать работу, когда у вас там полный бардак и система пришла в неработоспособное состояние.
Ну а Assert'ы при отладке и так вроде как все используют. Другое дело часто этого не достаточно.
Принцип «Fail Fast!» в разработке приложений