Сообщение Re[15]: Result objects - все-таки победили Exceptions? от 13.01.2025 20:32
Изменено 13.01.2025 22:05 SkyDance
Re[15]: Result objects - все-таки победили Exceptions?
·>Я не очень понимаю. Как на ерланге написать код вроде
Язык позволяет и result objects, и exceptions, так что — вот пример.
У здорового Эрланг-программиста код будет выглядеть так:
Однако есть довольно заметная секта поклонения тайпчекерам/result objects, у них будет так:
Я уж и не знаю, как от этого отучать "умудренных опытом программистов на <.вставьте свое.>".
·>Ну вот в случае parse — где им положено?
Там, где эту ошибку можно обработать. Очень часто это на самом высоком уровне, вплоть до "упасть с сообщением об ошибке". Обычно оно так и есть, но в некоторых случаях бывает, например, что можно попробовать другой парсер (в качестве fallback).
·>Про erlang я очень плохо знаю. Поэтому не очень понял суть этого высказывания.
Концепция простая, если разобраться. Представь, что для каждой функции ты можешь задать, сколько раз ее retry'ить, и что делать, если в течение N секунд происходит более M ретраев (классический вариант — ретрайнуть функцию уровнем повыше). Мда, корявое вышло объяснение. Для более осмысленного, лучше прочитать диссер Джо Армстронга, про error handling как раз — https://erlang.org/download/armstrong_thesis_2003.pdf
·>Так сложно вести беседу. Получается: "А вот исключения такие-то", а ты "но вот в криво отформатированном коде всё плохо". Отформатируй код по-другому. Делов-то..
Исключения позволяют писать более простой и понятный код. Как только начинается boilerplate в этих result objects, да умноженное на "копроративное форматирование кода", получается швах.
Язык позволяет и result objects, и exceptions, так что — вот пример.
У здорового Эрланг-программиста код будет выглядеть так:
add(Left, Right) ->
parse(Reft) + parse(Right).Однако есть довольно заметная секта поклонения тайпчекерам/result objects, у них будет так:
add(Left, Right) ->
case parse(Left) of
{ok, ParsedLeft} ->
case parse(Right) of
{ok, ParsedRight} ->
ParsedLeft + ParsedRight;
{error, Reason} ->
{error, {right, parse_failed, Reason}}
end;
{error, Reason} ->
{error, left_parse_failed, Reason}
end.Я уж и не знаю, как от этого отучать "умудренных опытом программистов на <.вставьте свое.>".
·>Ну вот в случае parse — где им положено?
Там, где эту ошибку можно обработать. Очень часто это на самом высоком уровне, вплоть до "упасть с сообщением об ошибке". Обычно оно так и есть, но в некоторых случаях бывает, например, что можно попробовать другой парсер (в качестве fallback).
·>Про erlang я очень плохо знаю. Поэтому не очень понял суть этого высказывания.
Концепция простая, если разобраться. Представь, что для каждой функции ты можешь задать, сколько раз ее retry'ить, и что делать, если в течение N секунд происходит более M ретраев (классический вариант — ретрайнуть функцию уровнем повыше). Мда, корявое вышло объяснение. Для более осмысленного, лучше прочитать диссер Джо Армстронга, про error handling как раз — https://erlang.org/download/armstrong_thesis_2003.pdf
·>Так сложно вести беседу. Получается: "А вот исключения такие-то", а ты "но вот в криво отформатированном коде всё плохо". Отформатируй код по-другому. Делов-то..
Исключения позволяют писать более простой и понятный код. Как только начинается boilerplate в этих result objects, да умноженное на "копроративное форматирование кода", получается швах.
Re[15]: Result objects - все-таки победили Exceptions?
·>Я не очень понимаю. Как на ерланге написать код вроде
Язык позволяет и result objects, и exceptions, так что — вот пример.
У здорового Эрланг-программиста код будет выглядеть так:
Однако есть довольно заметная секта поклонения тайпчекерам/result objects, у них будет так:
Я уж и не знаю, как от этого отучать "умудренных опытом программистов на <.вставьте свое.>".
·>Ну вот в случае parse — где им положено?
Там, где эту ошибку можно обработать. Очень часто это на самом высоком уровне, вплоть до "упасть с сообщением об ошибке". Обычно оно так и есть, но в некоторых случаях бывает, например, что можно попробовать другой парсер (в качестве fallback).
·>Про erlang я очень плохо знаю. Поэтому не очень понял суть этого высказывания.
Концепция простая, если разобраться. Представь, что для каждой функции ты можешь задать, сколько раз ее retry'ить, и что делать, если в течение N секунд происходит более M ретраев (классический вариант — ретрайнуть функцию уровнем повыше). Мда, корявое вышло объяснение. Для более осмысленного, лучше прочитать диссер Джо Армстронга, про error handling как раз — https://erlang.org/download/armstrong_thesis_2003.pdf
·>Так сложно вести беседу. Получается: "А вот исключения такие-то", а ты "но вот в криво отформатированном коде всё плохо". Отформатируй код по-другому. Делов-то..
Исключения позволяют писать более простой и понятный код. Как только начинается boilerplate в этих result objects, да умноженное на "копроративное форматирование кода", получается швах.
Язык позволяет и result objects, и exceptions, так что — вот пример.
У здорового Эрланг-программиста код будет выглядеть так:
add(Left, Right) ->
parse(Reft) + parse(Right).Однако есть довольно заметная секта поклонения тайпчекерам/result objects, у них будет так:
add(Left, Right) ->
case parse(Left) of
{ok, ParsedLeft} ->
case parse(Right) of
{ok, ParsedRight} ->
ParsedLeft + ParsedRight;
{error, Reason} ->
{error, {right, parse_failed, Reason}}
end;
{error, Reason} ->
{error, {left_parse_failed, Reason}}
end.Я уж и не знаю, как от этого отучать "умудренных опытом программистов на <.вставьте свое.>".
·>Ну вот в случае parse — где им положено?
Там, где эту ошибку можно обработать. Очень часто это на самом высоком уровне, вплоть до "упасть с сообщением об ошибке". Обычно оно так и есть, но в некоторых случаях бывает, например, что можно попробовать другой парсер (в качестве fallback).
·>Про erlang я очень плохо знаю. Поэтому не очень понял суть этого высказывания.
Концепция простая, если разобраться. Представь, что для каждой функции ты можешь задать, сколько раз ее retry'ить, и что делать, если в течение N секунд происходит более M ретраев (классический вариант — ретрайнуть функцию уровнем повыше). Мда, корявое вышло объяснение. Для более осмысленного, лучше прочитать диссер Джо Армстронга, про error handling как раз — https://erlang.org/download/armstrong_thesis_2003.pdf
·>Так сложно вести беседу. Получается: "А вот исключения такие-то", а ты "но вот в криво отформатированном коде всё плохо". Отформатируй код по-другому. Делов-то..
Исключения позволяют писать более простой и понятный код. Как только начинается boilerplate в этих result objects, да умноженное на "копроративное форматирование кода", получается швах.