Да, это применимо везде, но важно отметить, в каком контексте оно предназначено для использования.Это означает , а не , что означает сбой приложения в целом, которое, как указывал @PeterM, во многих случаях может быть катастрофическим.Цель состоит в том, чтобы создать систему, которая в целом никогда не дает сбоев, но может обрабатывать ошибки внутренне.В нашем случае это были телекоммуникационные системы, которые, как ожидается, будут иметь простои порядка минут в год.
Базовая конструкция состоит в том, чтобы наслоить систему и изолировать центральные части системы для контроля и управления другими частями, которыевыполнять работу.В терминологии OTP мы имеем супервизор и рабочий процессы.У супервайзеров есть функция наблюдения за работниками и другими супервизорами с целью их правильного перезапуска в случае сбоя, когда рабочие выполняют всю фактическую работу.Правильное структурирование системы по уровням с использованием этого принципа строгого разделения функциональных возможностей позволяет изолировать большую часть обработки ошибок от рабочих до супервизоров.Вы пытаетесь получить ядро с ошибкой small , которое в случае ошибки может обрабатывать ошибки в любой части остальной системы.Именно в этом контексте предполагается использовать философию «дай-ей-сбой».
Вы получаете парадокс того, что вы думаете об ошибках и сбоях повсюду с целью их фактической обработки какв нескольких местах, насколько это возможно.
Лучший подход к обработке ошибки зависит, конечно, от ошибки и системы.Иногда лучше попытаться отловить ошибки локально внутри процесса и попытаться обработать их там с возможностью повторного сбоя, если это не сработает.Если у вас есть несколько рабочих процессов, которые взаимодействуют друг с другом, то часто лучше их всех вывести из строя и перезапустить.Это супервизор, который делает это.
Вам нужен язык, который генерирует ошибки / исключения, когда что-то идет не так, чтобы вы могли перехватить их или вызвать сбой процесса.Просто игнорировать возвращаемые значения ошибок - это не одно и то же.