Являются ли несовместимые и отказоустойчивые принципы обработки исключений несовместимыми?

Question

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

На первый взгляд мне кажется, что отказоустойчивость означает, что мы хотим, чтобы система явно отказывала, когда происходит какая-то неожиданная вещь. Я имею в виду, например, если фабрика не может создать экземпляр объекта, по принципу отказоустойчивости мы действительно не хотим, чтобы фабрика возвращала нулевой или пустой объект, или частично инициализированный объект, который мог бы, случайно, использоваться правильно приложением -> в большинстве случаев мы будем иметь неожиданное поведение или неожиданное исключение, возникающее на другом уровне, которое не позволит нам узнать, что на самом деле происходит на фабрике. Это что означает этот принцип?

Принцип отказоустойчивости довольно сложен для меня. Наиболее распространенный пример в Java - о коллекциях, их итераторах и параллельном доступе. Говорят, что коллекция / итератор, который позволяет изменять список при переборах, называется отказоустойчивой. Обычно это делается путем итерации по копии исходного списка. Но в этом примере я не совсем понимаю, где происходит сбой системы ... и, следовательно, пока она отказоустойчива ... Где сбой? Мы просто перебираем копию или нет, в зависимости от наших потребностей ... Я не вижу соответствия с вики определением отказоустойчивости ...

Таким образом, в таких статьях, как: http://www.certpal.com/blogs/2009/09/iterators-fail-fast-vs-fail-safe/ Они напротив от отказоустойчивого до отказоустойчивого ... я просто не понимаю, почему мы называем отказоустойчивым эту итерацию поверх копии ...

Я нашел еще один пример здесь: http://tutorials.jenkov.com/java-exception-handling/fail-safe-exception-handling.html Кажется, гораздо больше связано с первоначальным определением принципа отказоустойчивости. Что я думаю о отказоустойчивости, так это то, что при сбое системы мы должны убедиться, что обработчик ошибок не вышел из строя, или, если это произойдет, убедиться, что настоящая первоначальная проблема не скрыта из-за сбоя обработчика. В данном примере обработчик находится рядом с исходным кодом ошибки, но это не всегда так. Отказоустойчивость означает для меня что-то вроде того, как мы правильно обрабатываем ошибки, которые могут произойти в обработчиках сбоя, или что-то в этом роде ...

Таким образом, для меня эти два принципа не кажутся несовместимыми. Как вы думаете? Разве система не может быстро и безопасно выйти из строя ???

Answer 1

Во-первых, лучше избегать сбоев (отказоустойчивость), но если это невозможно, лучше всего быстро срываться (как можно быстрее).

Два не являютсяпротивоположны, но дополняют друг друга.

Как вы говорите, мне нравится, чтобы мой код был максимально безопасным, но там, где это не так, я хочу, чтобы он быстро отказывал.

Answer 2

отказоустойчивость не означает, что что-то не выйдет из строя - это означает, что когда оно выходит из строя, оно выходит из строя безопасным способом. Что-то, что не может выйти из строя - это доказательство отказа - это возможно вообще.

Отказоустойчивый лифт заклинивает на своем нынешнем месте в случае обрыва кабеля. Гонщики неудобно застряли, но удобно не мертвы.

Рассмотрим пример итератора. Теория состоит в том, что лучше немедленно сообщить клиентскому коду о том, что что-то не так, чем слепо возвращать правильный ответ, который может вызвать более серьезные проблемы в будущем. Если клиентский код заботится о безопасности, у него есть возможность немедленно вмешаться и восстановиться. Таким образом, в этом случае отказоустойчивый и отказоустойчивый совместимы, последний является стратегией для достижения первого.

С другой стороны, рассмотрим веб-браузер в руках того, кто не знаком с компьютерами. Они пытаются увидеть, когда начинается их фильм. Допустим, что (не дай бог) HTML-код на странице не является правильно сформированным. Если средство рендеринга терпит неудачу быстро, оно может решить отказаться от рендеринга информации, которую хочет видеть пользователь, потому что предыдущий тег <HR> написан <H>. В этом случае лучше просто промахнуться, сделав страницу как можно лучше. Ошибка может быть незначительной и никогда не обнаруживаться, или она может быть обнаружена значительно позже, когда кто-то наконец заметит, что страница выглядит не совсем правильно. Итак, вот пример, где fail fast не является хорошей стратегией для fail safe .

Если бы веб-страница была моим приложением для онлайн-банкинга, я бы, конечно, хотел, чтобы она эффектно взорвалась (с откатом, конечно), если малейшая вещь пойдет не так. Итак, fail fast снова становится стратегией выбора для fail safe .

Я хочу сказать, что отказоустойчивость сама по себе является концепцией, и что отказоустойчиво может быть или не быть конкретной техникой, способствующей безопасности при отказе.