Информация об изменениях

Сообщение Re[15]: Result objects - все-таки победили Exceptions? от 13.01.2025 20:32

Изменено 13.01.2025 22:05 SkyDance

Re[15]: Result objects - все-таки победили Exceptions?
·>Я не очень понимаю. Как на ерланге написать код вроде

Язык позволяет и 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, так что — вот пример.

У здорового Эрланг-программиста код будет выглядеть так:
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, да умноженное на "копроративное форматирование кода", получается швах.