Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО

Original author: Christian Neumanns
  • Translation
image
Когда в приложении происходит ошибка, есть два диаметрально противоположных подхода к обработке этой ошибки:
Forgive! подход: приложение продолжает выполняться и старается минимизировать последствия ошибки.
Fail Fast! подход: приложение немедленно прекращает работу и сообщает об ошибке.
  • Какой из подходов лучше?
  • Какой подход стоит реализовать в своем приложении?


Чтобы ответить на эти вопросы посмотрим на простой пример.

Предположим мы должны написать простую веб-страницу, которая отображает рядом с фонтаном предупреждение о том, что вода в нём загрязнена.
Следующий HTML-код выполняет эту задачу:
<html>
   <body>
      <h2 style="color:red;">Important!</h2>
      <p>Please <b>DO NOT</b> drink this water!</p>
   </body>
</html>

Результат работы этого кода в браузере будет выглядеть следующим образом:
image

Теперь мы сделаем небольшую ошибку внутри HTML-кода.
Вместо тэга мы используем тэг
 после слов DO NOT, как в этом примере:
<p>Please <b>DO NOT<b> drink this water!</p>

Возникают два вопроса:
  • Что должно произойти?
  • Что произойдет?


На второй вопрос легко ответить. Достаточно выполнить ошибочный HTML-код в браузере. На момент написания статьи браузеры Firefox, Google Chrome, Internet Explorer, Opera и Safari покажут следующий результат:
image

Очевидно, что в браузерах используется подход Forgive!, так как наш сайт продолжил работу и не было никаких сообщений об ошибке. Единственное отличие в том, что теперь стало больше текста, выделенного жирным шрифтом. Но всё сообщение всё ещё отображается целиком и люди предупреждены. Незачем сильно беспокоиться!

Делаем вывод: подход Forgive! работает хорошо!

Давайте попробуем воспроизвести другую ошибку.Вместо тэга мы напишем незаконченный тэг <b перед словами DO NOT, следующим образом:
<p>Please <b DO NOT</b> drink this water!</p>

Ранее перечисленные браузеры покажут следующий результат:
image

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

Делаем вывод: подход Forgive! работает плохо!

Обращаю Ваше внимание на тот факт, что вышеприведённый пример - не просто теоретическое упражнение. Существует огромное количество реальных примеров, когда "маленькая ошибка" приводит к катастрофическим последствиям. Например, космический аппарат Mariner 1 взорвался после отрыва от земли из-за "отсутствующего дефиса". Больше примеров Вы можете найти на странице List of software bugs.


Как видно из приведённых примеров, последствия ошибки при использования Forgive! подхода очень отличаются и могут варьироваться от полностью безобидных до катастрофических. Итак, каким будет корректный ответ на вопрос "Что должно произойти?"

Как это обычно бывает, всё зависит от ситуации. Есть, однако, несколько основных правил.
Первое правило:
  • В процессе разработки всегда надо использовать Fail fast! подход


Рациональность данного правила описывается двумя простыми фактами:
  • Подход Fail fast! помогает в отладке. Как только что-то пошло не так, приложение останавливается и показывает сообщение об ошибке, которое позволяет зафиксировать, диагностировать и исправить ошибку. Таким образом, Fail fast! подход помогает писать более надёжное ПО. В результате значительно уменьшается стоимость разработки и поддержки, а также снижаются риски поломки приложения после релиза.
  • Последствия ошибок, возникающих в процессе разработки, минимальны и не критичны. Клиенты не жалуются, деньги не переводятся на неверный аккаунт и ракеты не взрываются.


Однако, ситуация кардинально меняется, когда приложение выполняется у клиента после релиза. К сожалению, не существует правила-на-все-времена. Практика показывает, что обычно лучше и после релиза использовать подход Fail fast! по умолчанию. Конечный негативный результат выполнения приложения, которое игнорирует ошибки и просто продолжает выполняться непредсказуемо, обычно хуже, чем негативный результат от приложения, которое внезапно прекратило работу. Если приложение бухгалтерского учёта внезапно "упало", пользователь будет зол. Если приложение продолжило работу после возникновения ошибки и создало неверный результат, пользователь будет очень зол. "Зол" лучше чем "очень зол". В этой ситуации подход Fail fast! лучше.

Есть исключения и каждая ситуация требует отдельной оценки. Это особенно актуально когда возможность серьёзных негативных последствий требует от нас тщательной оценки каждой ситуации, например как в случае с медицинскими приложениями, приложениями по переводу денег или приложениями космической программы. Например, применение подхода Fail fast! оправдано до тех пор, пока мы не отправляем ракету на Марс. Но как только ракета стартовала - остановка приложения больше не вариант. Теперь должен применяться подход Forgive! в комбинации с режимом "делай лучшее что ты можешь".

Иногда хороший вариант - использовать Fail fast!, но при этом минимизировать негативный эффект от ошибки. Например, если произошла ошибка в текстовом редакторе, приложение должно сначала автоматически сохранить набранный текст во временный файл, затем вывести сообщение для пользователя ("Извините, ... но ваша работа сохранена в файл abc.tmp"), опционально послать отчёт разработчику и только потом прекратить работу.

Можно заключить:
  • В процессе разработки всегда стоит использовать Fail fast! подход.
  • После релиза:
    • По умолчанию стоит всегда отдавать предпочтение подходу Fail fast!.
    • В случае с критичными приложениями, которые имеют риск создания серьёзного негативного эффекта в случае возникновения ошибки, должны применяться индивидуальные решения, зависящие от контекста с целью минимализации негативного эффекта. В случае, когда ситуация после ошибки чётко просчитана, должен применяться подход Forgive! с правильной реакцией на произошедшее.



Та же идея описана в главе Rule of Repair книги The Art of Unix Programming , написанной Эриком Реймондом:
Почини когда можешь - но когда ты должен упасть, падай громко и как можно скорее.


В этом контексте также имеет смысл вспомнить заповедь номер 6 из Десяти заповедей С-программиста , написанных Гарри Спенсером:
Если функция возвращает код ошибки в случае возникновения трудностей, ты должен проверить код этой ошибки, даже если эта проверка троекратно увеличит размер кода твоего и вызовет боль в твоих пальцах, потому что если ты помыслишь "это не может случиться со мной", боги обязательно накажут тебя за высокомерие.


В любом случае, твой лучший друг - это среда разработки, которая поддерживает Fail fast! подход. Например, компилируемые языки придерживаются правила Fail fast! потому, что компиляторы могут немедленно сообщить о всём изобилии ошибок в коде. Приведу пример тупой ошибки, которая может быть легко не замечена человеческим глазом и может привести к неприятным сюрпризам в процессе выполнения, но при этом немедленно и наверняка вылавливается компилятором:
var table_row_index = 1
...
table_row_indx = table_row_index + 1


Контрактное программирование ещё один пример использования особенностей Fail fast!. Потому что неверные входные/выходные аргументы и атрибуты объектов немедленно определяются и вызывают ошибки в процессе выполнения.

Есть еще множество особенностей реализации Fail fast! , которые могут быть встроены в язык программирования. Они основываются на следующем правиле:
  • Желательно, чтобы ошибка автоматически выявлялась на этапе компиляции или, как можно проще и быстрее, в процессе выполнения.


Если Вы выбрали среду программирования (= язык программирования + библиотеки + фреймворки), которая придерживается этого важного правила, то Вы будете отлаживать меньше и создавать более надёжный код за меньшее время.

Дополение от переводчика:
Вспыло утверждение, дескать никто не будет делать две версии кода, одну с fail fast для разработки и вторую без fail fast для релиза.
Меня это утверждение немного удивляет.
Есть весьма распространенное решение этого вопроса. Assert
В релизе он убирается автоматически. Таким образом код являющися fail fast в дебаге перестает быть таковым в релизе.
Никаких проблем, и уж тем более переписывания кода - нет.
Share post

Similar posts

Comments 73

    –3
    Расскажите про принцип fail fast в отношении операционной системы. Итак, у вас код операционной системы обнаружил, что драйвер звуковой карты на сервере некорректно заполнил структуру данных, отвечающих за обработку пятиканального звука при работе с bluetooth устройствами.

    Ваши предложения?
      +11
      Цель вашего вопроса показать, что fail fast не применим в 100% случаев?
      Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.
        +9
        Ответ достаточно очевиден:
        Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
        Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
        fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.
          +8
          Ну так ведь смысл не в том, что ОС должна сразу упасть, а в том, что не должна пытаться эту неправильную структуру интерпретировать, при этом падать совсем не обязательно, как писали выше, достаточно выгрузить драйвер и честно сообщить об ошибке.
            +1
            Я думаю, что Fail Fast должен работать на уровне независимых модулей. В данном случае на уровне драйвера.
            Ну кроче применять этот принцип надо с умом.
              0
              Все принципы надо применять с умом. :)
              В программировании подругому и не бывает.
                0
                Если еще точнее — граница применения fail fast ограничивается зоной затронутого операцией состояния (которое в результате неожиданной ошибки становится неопределённым — т.е., в частности, неизвестно, выполняются ли контрактные инварианты). В идеале, разумеется, для этого используются механизмы гарантированной изоляции изменений состояния — и это могут быть и грубые средства вроде процессов, и более легковесные альтернативы вроде дотнетовских аппдоменов, и языковые фичи типа монад или STM.
              +6
              Fail Fast — не означает что нужно обязательно приложению падать. Речь о том, чтобы прервать выполнение текущей операции, чтобы избежать неопределенности ее дальнейшего выполнения. В реальности случаи, когда можно забыть о том, что произошла ошибка и исполнять код дальше — очень редки в софтверной индустрии. Хотя код такой пишут очень часто. Особенно грешат этим создатели автоматизированных скриптов. Поэтому можно более менее уверенно говорить что в общем Fail Fast это хорошо, а Forgive это плохо.
              Хотя конечно есть исключения.

              Что же касается того, нужно ли обрабатывать ошибки на местах — то есть нужно ли тратить ресурсы на обработку описанной вами ситуации — то совершенно другая тема. В целом главный вопрос в том — является ли ошибка внешней или внутренней по отношению к программе. Если она внешняя — значит это тоже часть интерфейса (возможного поведения) внешнего использованного сервиса (у вас драйвера) и нужно конечно ее обрабатывать и правильно на нее реагировать.
                +2
                BSOD
                  0
                  Насколько я понимаю, именно так и появилась микроядерная архитектура :);
                    –2
                    И где эта ваша микроядерная архитектура irl?
                      +1
                      В QNX?
                        –3
                        И где этот ваш qnx?
                          0
                          www.qnx.com/company/30ways/

                          Стыдно, товарищ.
                            0
                            Я вижу обратное — практически всё сетевое оборудование и схд работают на базе freebsd, linux, вендоры автомобилей массово переползают на линукс.
                              0
                              Про то, как «вендоры автомобилей массово переползают на линукс» особенно хотелось бы ссылочку.
                                  +1
                                  А вы дальше заголовка-то читали?

                                  ...Linux will quickly grow to represent 20 percent of automotive computers by 2018, pulling closer to Microsoft behind industry-leading QNX.

                                  Currently, BlackBerry’s QNX Software and Microsoft’s Windows Embedded Automotive together account for around 75 to 80 percent of the market, says ABI.

                                  :D
                                    –1
                                    Это я и называл «переползают». Кратковременный взлёт проприентарной системы перед тем, как люди уткнутся в проблему невозможности самим почесать себе чешущееся место. После чего приходят свободные системы.
                                      +2
                                      Диванные аналитики такие диванные…
                                        0
                                        А вот что говорят реальные аналитики:
                                        “With the pace of change in automotive still being quite slow, the mid-term future for QNX still looks bright. Plus QNX has the important advantage of having a tried and tested optimized solution. Hence, QNX is still an attractive solution for a risk-averse automotive industry.”
                                        Что как бы слегка противоречит вашему «авторитетному» мнению по данному вопросу.

                                        К тому же мы ушли от темы. Вы спрашивали «где этот вам QNX?», после чего сами же привели ссылку, которая гласит, что QNX и Microsoft владеют от 75% до 80% рынка автомобильных систем. Плюс к этому там утверждается, что года через 4 «Linux приблизится к Microsoft и будет иметь около 20%». То есть получается, что Microsoft имеет ненамного больше этого. То есть можно смело сделать вывод, что QNX владеет примерно половиной рынка автомобильных систем.

                                        Полагаю, уже одно это отвечает на ваш вопрос «где этот ваш QNX».
                                          0
                                          Плюс к этому там утверждается, что года через 4 «Linux приблизится к Microsoft и будет иметь около 20%»

                                          Google уже запустил Open Automotive Alliance, поэтому вслед за смартфонами и планшетами, Google выдавит Blackberry ещё с одного рынка. Засекайте, через 4 года QNX на фронтенде и мультимедийных системах в авто не будет, останется только в кишках. :)
                                            0
                                            Засекаю, мне не сложно. Google Calendar отлично работает для таких вещей :)

                                            Очень уж люблю «аналитиков», которые увидев знакомые слова «Google» и «BlackBerry», моментально проецируют ситуацию на одном рынке на другой, несмотря на то, что между ситуациями различий куда больше, чем сходств.
                                              0
                                              Если не сложно, отпишитесь здесь когда напоминалка придет. Думаю многим было бы интересно подвести итог.
                                                0
                                                Договорились :)
                                                0
                                                Инфа сотка вообще. Blackberry тут на ладан дышит, и никому не нужна, так что всё ок :)
                                                  0
                                                  Вот уж что-что, а QNX никуда не пропадет даже если BlackBerry завтра сколлапсится.
                                                +1
                                                >>>Засекайте, через 4 года QNX на фронтенде и мультимедийных системах в авто не будет

                                                Итак, прошло 4 года (без одного дня).

                                                Mairon, не хотите признать, что были неправы? ;)

                                                blogs.blackberry.com/2018/01/blackberry-qnx-at-ces-2018-featuring-safe-and-secure-foundational-software-for-the-automotive-future

                                                AllexIn, отписываюсь, как обещал.
                                                  0
                                                  ССыль залочена по решению роскомпозора. :(
                                                    0
                                                    Вкратце, если кто из России: на CES Blackberry выкатили версию QNX для демонстрации с Астон мартином и Ренджровером. Добавлены всякие фишечки, типа запуска Андроид приложений и использования в ситема автопилота.
                                                      0
                                                      Хренасе события развиваются в «великой и могучей»… о_О

                                                      Чем им BlackBerry-то «икстримизьмом» запахло?


                                                      (кликабельно)
                                    +2
                                    Цитата из ru.wikipedia.org/wiki/QNX:

                                    На март 2009 года решения на базе QNX лицензированы для использования на более, чем 10,1 миллионах единиц техники от практически всех ведущих производителей автомобилей, включая BMW, Chrysler, Daimler, Fiat, Ford, General Motors, Honda, Hyundai, Mazda, Mitsubishi, Nissan, Saab, SsangYong, Toyota и Volkswagen. В частности, такие автомобили выпускаются под марками Acura, Alfa Romeo, Audi, Buick, Cadillac, Chevrolet, Dodge, Honda, Hummer, Infiniti, Jeep, Lancia, Mini, Mercedes, Opel, Pontiac, Saturn и другими.


                                    Ещё вопросы :)?
                                      0
                                      Итого, 10 миллионов единиц техники. Сколько у нас автомобилей с компьютерами продаётся ежегодно? Гугление, вроде бы, показывает около 80 миллионов. Допустим, средний срок эксплуатации 5 лет. Итого — 400 к 10. 2.5% рынка. Круто!
                                        +1
                                        10 миллионов — это кагбэ только в 2009-м году. Список кагбэ растет и ширится. Например, Ford drops Microsoft, will use BlackBerry’s real-time OS for next Sync. Даже эппловский iCar под капотом имеет QNX.

                                        А вообще вы очень удобно из 30 пунктов выбрали несколько штук, снабдили это «авторитетным» источником «Я вижу обратное» и почему-то уверены, что у вас получилось весомое возражение. Жжоте, однако :D
                                          0
                                          «Я вижу» — это Juniper, разумеется. И остальной коммутационно-схдшный бизнес.

                                          А цифру «10 миллионов» привёл не я. Даже если предположить, что это «10 миллионов в год», то это всего лишь 12.5% машин в год.
                                            0
                                            См. выше. Вы сами же и привели отличную ссылку :)
                            +7
                            Как разработчик я, может быть и одобряю Fail Fast, но как пользователь — ненавижу. Потому что в 999 случаях из 1000 у пользователя нет возможности дождаться исправления ошибки программистом в адекватное время, а результат работы программы нужен здесь и сейчас, пусть и с ошибкой, которую пользователь может попытаться исправить самостоятельно.
                              +1
                              Тут есть нюанс.
                              Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
                              Но сейчас ситуация иная.
                              Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
                              На Андроиде так вообще уже встроенная система отчетов используется.

                              Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.
                                +1
                                Хм. Два часа ночи дают о себе знать.
                                «не было никакого смысла отправлять в релиз ПО с fail fast»
                                «нет никакого смысла в том»
                                «автоматизируют обработку ошибок и отправку отчетов на Windows»
                              +2
                              Исключения — наши друзья )
                                +1
                                После того как написал текст про исключения мне были представлены два факта:
                                1) Текст получился сумбурным
                                2) Я описал Fail fast! подход.
                                Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.
                                –1
                                >> Делаем вывод: подход Forgive! работает плохо!

                                Я сделал только один вывод: автор склонен предоставлять примеры однобоко, дабы поспешные выводы из них не противоречили сути статьи.

                                Существует бесчисленное множество примеров когда Forgive спасало жизнь (например полёт Гагарина). Также немало примеров когда Fail fast позволило предотвратить катастрофические ситуации и тоже спасало жизнь.
                                Поэтому говорить, что подход X нужно чаще использовать нельзя.

                                Единственное за что нужно агитировать, чтобы разработчики чаще включали мозг.
                                  +1
                                  До конца не читал, зато коммент написал?
                                    0
                                    Дочитал, дочитал. Статья на всём протяжении изобилует агитацией к Fail fast подходу, поэтому мой коментарий корректен.
                                      0
                                      Основная претензия к вашему комментарию в том, что вы описали тезисы из статьи как однобокие, при этом практически полностью повторив их
                                    0
                                    Пример про Гагарина — один в один пример про ракету на Марсе из статьи. Где как раз и говорится, что в этой ситуации надо использовать Forgive.
                                    Действительно создается ощущение что статьюв ы не дочитали.
                                      –8
                                      А по сути коментария есть что сказать?
                                      +1
                                      Не знаю как там у Гагарина или где то еще в космосе.

                                      Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко. Это практически всегда специфика предметной области. Типичная ошибка в программе как правильно приводит к неопределенному поведению, которое дальше уже нельзя контролировать. А значит нужно остановить.
                                      Исключения в прикладной софтверной индустрии не часты. Поэтому мы и можем сказать что хорошо, а что плохо.

                                      А то, что принцип Fast Fail по ошибке воспринимают как необходимость «уронить» все приложение — это отдельная песня.

                                      Что касается вашей последней фразы — знаете — знания и практические шаблоны как раз и создают для того, чтобы не включать мозг. Потому что его можно задействовать где то еще — не задумываясь над каждой строчкой — нужно ли тут применять Forgive. А вместо этого уделив больше внимания чему нибудь другому на проекте на каком нибудь более высоком уровне абстракции.
                                        –2
                                        У нас с вами противоречие в терминологии, что делает бесполезным всю дальнейшую дисскусию.

                                        Вот например:
                                        >> Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко.
                                        Да, ладно, весь веб на динамических языках(PHP, JS, Python, Ruby) + HTML + CSS — это один большой Forgive.
                                        В оконном софте неработоспособность одной фичи — не значит, что нужно убивать приложение.

                                        А вот в любом потоковом процессе, где нас интересует или конечный результат или отсутствие деструктивных действий, там нужен Fail fast (банковские транзакции, кодирование/декодирование). И вот, на мой взгляд, софт обычно включает такие процессы а не полностью состоит из них.

                                        С большой печалью прочитал ваш последний абзац. Не согласен:
                                        * Знания не создают, а накапливают, приобретают
                                        * Шаблоны создают для стандартизации подходов, что приводит к лучшей передачи знаний. Да, шаблон напоминает тебе о чём нужно не забыть подумать, но это скорее побочный эффект. Да и далеко не все ньансы этим описываются. Кроме того теперь нужно ломать голову над тем, какой шаблон выбрать.
                                        * Ну и мозг это не 100 минералов. Типа сэкономили в одном месте и можем лучше подумать в другом. Можно задумываться над всеми ньансами софта. И чем больше мы будем думать и чем меньше мы напишем кода, тем будет лучше.
                                          0
                                          Не вижу никакого противоречия в терминологии. Что вы имеете ввиду?

                                          Вы правы — в вебе часто работает Forgive — а вот хорошо это или плохо — вопрос хороший. Лично я считаю, что например в случае с HTML — это просто наследие, от которого мы не можем отказаться из-за уже созданных приложений. Для меня было бы сказкой — если бы разметка «падала» в случае поломки — тогда не понадобилось бы затрачивать такие усилия по определению UI проблемы в авто тестах на UI. Вообще дополнительные валидации динамического кода на статическую корректность — это необходимость.

                                          В большинстве динамических языков (PHP, Javascript и т.д.) есть исключения останавливающие выполнение работы программы. И если они применяются для разработки интерпрайз решений — то уход от Forgive подхода — обычно необходимый и правильный шаг.

                                          В оконном софте тоже есть поведение верно? И там тоже есть операции которые подразумевают какой то результат. Вот как раз Fast Fail и подразумевает что операция не будет завершена если произошло исключение. Я еще раз повторю — что это не значит что нужно убивать приложение. Забудьте уже про этот стереотип. Но обработка ошибок тут будет комплексная на уровне приложения, а не локализованная. Можно сделать так, что этом внешне это не затронет других фич. Это не проблема.

                                          Софт конечно не состоит полностью из процессов — вы правы. Он состоит из процессов (поведения) и деклараций (UI например) - это просто модель :). Поведение обычно занимает значимую часть бизнеса приложение — чаще всего большую часть. Вышеописанные подходы актуальны прежде всего для поведения. Ваш пример про банки — это транзакции. Это не то же самое о чем говорю я. Транзакции подразумевают возможность отката. Тут же откат не нужен. Мы просто избегаем некотролируемого поведения вот и все. Не только в данной операции, но и во всех дальнейших, которые от нее могут так или иначе зависеть.

                                          Fast Fail для интерпрайз решений — это настоящая best practic — он позволяет избежать рисков на продакшене и выявлять и фиксать проблемы быстрее. Чаще всего прежде чем это попадет к пользователю. Потому что чем позже выявляется дефект — тем он дороже.

                                          Но я допускаю, что в наколеночных поделках это может быть не так важно.
                                            0
                                            У меня сложилось мнение, что мы в целом об одном и том же разными словами. Благодарю вас за потраченное время.
                                          0
                                          Позвольте предложить довольно частый пример: если приложение содержит GUI и в нем присутствуют чисто отображающие (read-only) элементы, то невозможность работы одного или нескольких таких элементов не должна влиять на логику работы приложения. В идеале, падение кода одной картинки на экране должно приводить программу либо к игнорированию (с отправкой отчёта разработчикам), либо к перезапуску этого элемента.

                                          При этом учитывая, что зачастую отображающие элементы имеют очень и очень сложное внутреннее устройство, вариант fail-fast для них плох — он дестабилизирует систему в целом.
                                            –1
                                            Вы можете гарантировать что ваш «GIU элемент» в процессе краша не влез в память где хранится переменная с номером счета клиента и в итоге не привел к отправке денег к черту на куличики?
                                            Если уверены то да, не надо падаться, надо обрабатывать и продолжать работу.
                                              0
                                              Прикол в том, что если обрабатывать все возможные проблемы всех элементов — то вам придется затратить куда больше ресурсов на реализацию. Это часто бывает очень не дешевым решением. И к тому же эти ресурсы трудно спрогнозировать. Да еще очень легко забыть что нибудь обработать. Потому что все возможные варианты крешей вы все равно не придумаете.
                                                0
                                                Простите, не уточнил — пишу на Java, где проблемы с памятью исключены, стремлюсь к полной инкапсуляции, то есть влияние одного объекта на другой исключено, если они не связаны функционально
                                                0
                                                Сам по себе подход Fast Fail и требование к «мягкому» поведению юая в случае падений вполне могут сосуществовать вместе. Они пересекаются постольку поскольку это является следствием особенностей архитектуры системы. Если она достаточно модульна — то использование Fast Fail не вызовет проблем. Иначе — ее можно улучшить.

                                                Например у меня был как то проект новостного сайта — там было требование в случае падений каких то элементов на странице (серверные контролы) они должны просто пропадать с экрана не меняя или ломая верстку и сайт в целом. Решилось это простым наследованием всех контролов от от одного базового класса с обработкой ошибок и базовыми клиентскими механизмами. Конечно при этом легко было включить Fast Fail на девелоперском и тестовом окружении. И отключить его (включив обработку ошибок) на продакшене. То есть мы могли вылавливать ошибки рано и при этом выполнять требования бизнеса по стабильности на настоящем развернутом сайте.
                                                Цена вопроса — несколько десяток строк кода и пару часов работы.

                                                Конечно конкретное решение в каждом случае будет зависеть от архитектуры конкретно вашей системы.
                                                Но общий подход к решению описанной вами проблемы такой: выделить модули (например ваши сложные видимо жаваскриптовые элементы) и внедрить комплексную обработку падений для всех таких модулей. Которую вы можете сконфигурировать на Fast Fail при девелопменте и определить более сложное поведение на другом окружении.
                                                Однако это ваше специальное поведене в случае падений элементов нужно конечно тестировать отдельно — так как это тоже часть бизнеса.
                                            +3
                                            Я в своих разработках придерживаюсь сбалансированного подхода. Если программа видит ошибку, которую возможно обработать без нарушения основных функций программы, и усложнение программы внедрением в нее обработчика оправдано — то обрабатываю. Во всех остальных случаях «падает» соответствующий уровень приложения. То есть прекращается выполнение запрошенной пользователем команды, освобождаются все связанные с этим ресурсы и выводится содержательное сообщение об ошибке. При этом все приложение не вылетает, оставляя пользователю возможность сделать повторную попытку или запросить какую-то другую функцию. Все приложение вылетает только, если на более высоком уровне обнаружена неисправимая ошибка.
                                              +1
                                              А как связаны «информирование разработчика об исключительной ситуации» с «восстановлением после сбоя»? Это перпендикулярные понятия. Ничто не мешает показывать разработчику ошибку большими красными буквами, отсылать ему отчеты и тп, при этом сохраняя потребительские свойства насколько возможно. В примере с фонтаном в случае с быстрым падением предупреждающего сообщения вообще выведено не будет. Это сильно лучше, чем очевидно некорректное «Осторожно! Пожалуйста, пейте воду из фонтана»? Предупреждение с непонятным текстом как минимум насторожит. Отсутствие предупреждения — нет.

                                              Вот за что я не люблю эти «постулаты» так это за то, что они решают одни проблемы за счет других. В результате оказывается, что все приложение оказывается неработоспособным из-за маленькой никому не нужной кнопочки в углу экрана. И самое печальное, что я так и не смог убедить «ведущего разработчика», что это не правильно, ибо «fail fast — best practice».

                                                +1
                                                Проблема с forgive не только и не столько в отсутствии диагностики, сколько в безопасности и надёжности софта. Например, если ваше приложение — это редактор, и при неожиданной ошибке вы будете пытаться сохранять работоспособность максимально долго, вы вполне можете дать пользователю уникальный шанс затереть редактируемый документ мусором, сохранив текущее «сломанное» (т.е. с нарушенными инвариантами) состояние вашей модели. А если это браузер, то forgive легко и непринуждённо может превратить одну маленькую дыру в безопасности в много больших…
                                                +2
                                                В нашем приложении мы используем следующий подход. При возникновении ошибки, высылается мейл админу с описанием ошибки, а пользователь получает сообщение «System busy, please try again later.». Пользователь не пугается и думает, что система работает как надо, просто в данный момент перегружена. А мы тем временем судорожно исправляем все ошибки :-)
                                                  0
                                                  Это нечестно!
                                                • UFO just landed and posted this here
                                                    0
                                                    Может быть я не правильно перевел?

                                                    Design by contract (TM) (also called Contract Programming) is another example of a Fail fast! feature. This is because invalid values for input/output arguments and object attributes are immediately detected and raise a program error at runtime.

                                                    There are many more Fail fast! features that can be built into a programming language.
                                                    0
                                                    А кстати, почему бы не продавать пользователям отдельно версию кода с Fail Fast за полцены? В итоге, кого бесят сообщения об ошибках и все эти «отправить репорт разработчикам?» — купят полную версию, желающие сэкономить — купят Fail Fast и будут репортить баги. Потока информации от второй группы будет достаточно, чтобы поддерживать в хорошем состоянии проект для всех.
                                                      0
                                                      ОБТ же и «Ранний доступ». Это в сфере игр. В сфере прикладного ПО не знаю, но уверен там есть аналогичные подходы.
                                                        0
                                                        Эм, ОБТ и «Ранний доступ» — это отнюдь не «Fail Fast» за полцены. ОБТ — это, вообще, о другом. ЗБТ и предшествующие тесты — это проверка различных гипотез (технических, игровых, прочих) на лояльных игроках, но при этом неразработчиках.
                                                        На счет игр. На стадии разработки: игровой сервер и игровой клиент должны быть максимально живучими, независимо от стадии готовности. Т.к. над их созданием трудится очень много людей.
                                                        В жизни сервер, например, имеет право упасть только во время старта — инициализации баз и прочее. Как только на сервер пошли игроки, он должен держаться до последнего (в рамках разумного).
                                                          0
                                                          ОБТ — это, вообще, о другом.

                                                          О чем?

                                                          ЗБТ и предшествующие тесты

                                                          Про ЗБТ ничего не говорил.

                                                          ОБТ и «Ранний доступ» — это отнюдь не «Fail Fast» за полцены.

                                                          Что же это, как не продажа за полцены забагованного приложения?

                                                          В жизни сервер, например, имеет право упасть только во время старта

                                                          В идеальном мире.
                                                          Вспомните сколько раз падали сервера Diablo 3 за время с его старта.
                                                            0
                                                            ОБТ для игр — это, фактически, релиз. В ОБТ игровые проекты живут достаточно долго — годами. Warface в ОБТ уже два года, и ничего :) Так что, приставка «ОБТ» — это отнюдь не повод серверам или клиентам падать.

                                                            Насчёт падения сервера — речь шла о Fail first. Что на момент инициализации — Fail first, дальше — Forgive, пока возможно. От ОБТ, «полцены» или «забагованного приложения» это не зависит. Это просто подход к проектированию сервера игр.

                                                            Насчет Diablo 3 ничего сказать не могу, у меня нет данных о том, что сервера падали. Были недоступны — это да, падали — не факт. Возможно, разработчики Diablo не предусмотрели механизм, позволяющий дать доступ ограниченному количеству пользователей с достойным UX, и решили объявить профилактику. Или, наоборот, закрыли доступ, чтобы хотя бы часть игроков смогла играть нормально. В любом случае, это не было «Fail Fast» за полцены, о котором говорил tangro. Т.к. альтернативы доплатить и поиграть нормально не было.
                                                              0
                                                              Альтернатива вполне была — заплатить, подождать и поиграть.
                                                      0
                                                      Я правильно понял, что все эти много букв можно сократить до «используйте assert() или аналогичную конструкцию»? :)
                                                        0
                                                        Ага. Но я пробовал написать это двумя словами, успеха не добился. :)
                                                        +1
                                                        > Почини когда можешь — но когда ты должен упасть, падай тихо и как можно скорее.
                                                        Оригинал: Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.

                                                        Правильный перевод «падай громко», и по логике это правильно, так как надо сообщить о проблеме
                                                          +1
                                                          Спасибо. Но лучше в личку.

                                                        Only users with full accounts can post comments. Log in, please.