ZET???

Это что-то вроде TDD? 🙂

zero errors tolerance

Zero Error Torlance

Есть еще ZWT

Туда же, но жоще

Хм... А в чём это на практике выражается?

use warnings FATAL => 'all';

?

Ну, как это с точки зрения кода выглядит. Заворачивание в кучу eval {} ?

Думаю что это не с точки зрения кода, а с точки зрения процессов разработки — если узнают про новый баг, но не делает никаких новых фич пока баг не починят

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

Соответственно код не должен падать в продакшене (и течь, кстати, тоже).

Если он упал - смска придет программистам и они будут чинить.

Обычно 1 eval на входе RPC запроса

Логично, что не должен, но назвать это какой-то методологией прямо...
Я могу проверить входные данные досконально и упасть, если там закорючка не соответствует регэкспу идеально. А могу не проверять вход досконально. в первом случае упаду через 15 минут, а во втором - через 3 года первый раз закорючка не в том месте приведёт к реальным проблемам.
Я исповедую подход "проверяй всё и не доверяй никому, по умолчанию всё, что вовне - подозрительно". Поэтому у меня на единицу кода плотность die или return'ов зашкаливает
А у кого-то их мало - и "всё работает".

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

Это немного не про то. Проверка входящих параметров - это, конечно, хорошо и верно. Я про отношение к коду. Что делать с ошибкой. Есть 3 подхода:
1) Подави ошибку и работай дальше. Например, в свое время, так делала Delphi. Если какой-то эвент падал с ошибкой, то находился его вызов и затирался. Прямо в рантайме.
2) Проверяй на все всегда. Яркий пример - Ява.
3) Дай упасть и почини. А лучше сделай так чтобы не падало.

Вот мы про последний.

fail fast и let it die, называется... подтырено в эрланге. Правда, там "самоизлечение" процесса подразумевается супервайзером... ну н
у нас по сути также, только самоизлечение более тяжёлое )

Я думаю что ErLang не сам до этого дошел. Так что не в нем...

Дай упасть и подробно сообщи, что пошло не так.
Ну в общем да, хороший подход. Больше всего меня выводят из себя python-исты, у которых приложения падают со стек-трейсом на 100К, а вся суть ошибки - "не найден файл конфигурации". Таких ***в я бы лично бил в лицо, просто ненависть каждый такой случай вызывает (это реально прямо 1-е место в top-10 "что меня бесит в чужом коде")