23 января 2011

Let it fail

Главная мантра при написании кода на Erlang — «Let it fail» («Пусть падает»).
Как гром среди ясного неба. А если быть точнее: как солнце среди миллиардов туч. Неужели кто-то думает так же как и я? Неужели не один я вижу конструкцию try/catch неудобной?

Все очень просто: разработчики языка Erlang взяли на себя ответсвенность за наши ошибки.
Вы чувствуете? Гора с плеч спала. Огромная такая гора вопросов:
Показывать или не показывать message box?
На каком уровне его показывать (вы же понимаете что вызывающая функция тоже может ловить ваши ошибки)?
А какие вообще исключения ловить, а что делать в catch(...)? А может стоит попробовать восстановить работоспособность, а что нужно тогда реинициализировать?
В серверном приложении пороще конечно, все просто пишем в лог. А если забыли какую-то функцию  обработать?

А тут ра-а-а-з, и всё. Тишина, спокойствие. Пишешь программу, как будто она будет жить вечно, и так и происходит. Принцип прост: программа аварийно завершилась, erlang ее перезапустил.

Вот ещё, нет глобальных переменных. Если функция завершилась неудачно, это значит неправильные параметры. И всё. Не надо искать какие-то там еще объекты, к которым обращается функция. Она ни к чему не обращается. Только к параметрам.

2 комментария:

  1. Ещё бы Эрланг бажную функцию сам переписал и передеплоил по всем нодам, а то от одних перезапускний толку маловато будет ;)

    ОтветитьУдалить
  2. Хе, я слукавил:) Это скорее защита от неверных данных из "дикой природы".

    ОтветитьУдалить