Когда «дать сбой» и когда защищать код в Erlang?

Таким образом, мантра Erlang с кодом «let it crash» должна быть устойчивой к таким жестоким мировым событиям, как неожиданное отключение, сбой оборудования и нестабильные сетевые подключения.

С другой стороны, естьоборонительное программирование.

Интересно, будучи новичком в Erlang, как узнать, когда я хочу, чтобы процесс просто аварийно завершился, и когда я хочу, чтобы он защищал поток с помощьюif, case..ofтипа охранников?

Скажем, у меня есть модуль аутентификации, который может вернутьtrue/false результат, если аутентификация прошла успешно или нет. Должен ли он иметь успешный сценарий и аварийно завершить работу, если аутентификация пользователя не удалась из-за неправильного логина / пароля?

А как насчет других сценариев, например, если продукт не найден в базе данных или результаты поиска пусты?

Полагаю, я не могу полностью игнорировать защитные конструкции, так как любые охранники по своей природе защищают «нормальный» поток приложения?

Есть ли эмпирическое правило, когда защищаться и когда терпеть крах?

Ответы на вопрос(2)

Практическое правило в этом случае.

Насколько я понимаю, всякий раз, когда вы знаете, как обрабатывать ожидаемую ошибку - обрабатывайте ее. В случае аутентификации, я не думаю, что это настоящая ошибка, это нормальное поведение, так что давайте напишем несколько строк кода для обработки этого конкретного случая.
Напротив, сбой в сети - это то, что может произойти по разным причинам, на самом деле они не ожидаются как часть нормального поведения вашего кода, поэтому в этом случае я бы придерживался философии «пусть случится сбой».

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

Пожалуйста, проверьте такжеэто очень хороший ответ, И вы можете прочитать больше об этомВот а такжеВот.

http://ferd.ca/the-zen-of-erlang.html -

Если я знаю, как обработать ошибку, хорошо, я могу сделать это для этой конкретной ошибки. В противном случае просто дайте ему разбиться!

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

Ваш ответ на вопрос