Элегантная обработка ошибок в JavaScript с помощью монады Either

[superconductor]

Ух ты, заново изобретены цепочки промисов, но синхронные и замысловатые. Хотя казалось бы, никто не мешает сделать
Promise.resolve().then(...).then(...)....catch(e=>...);
Ну правда результат получится упакован в промис

[VolCh]

Интуитивно кажется, что изобретатели промисов имели в виду эти цепочки, делая свои. То есть промисы это что-то вроде этой монады, но асинхронное.

[Finesse]

А потом придумали async & await, чтобы вернуть обработку ошибок обратно к try & catch.

[L2jLiga]

Любая async функция возвращает Promise.rejected в случае если в ней произошла ошибка, так что можно во внешней функции спокойно ловить с помощью .catch()

[the_o]

Я могу, конечно, ошибаться, но с тех пор как я поверхностно познакомился с хаскеллем, мне не перестаёт казаться, что это наоборот — промисы были ну очень сильно вдохновлены его монадой Either. А точнее, они её прямая (со скидкой на асинхронность) реализация, призванная вытащить асинхронный код из того callback-hell'а, в котором он ещё недавно пребывал. Хотя если судить по тому, что давеча завезли async/await — монады пришлись js-сообществу не очень-то по вкусу, и оно предпочло и дальше по-старинке try-catch'ить.

[VolCh]

А в какой момент простая функция превратилась в монаду? :)

А если серьёзно, то именно для обработки ошибок все эти left, right, map напрягают. Есть ссылка на какой-то алгебраический стандарт, но непонятно неподготовленному читателю причём тут алгебра вообще. Кажется, что лучше бы зашло использование "нативных" для обработки ошибок имён, а уж в конце рассказать о этой алгебре и стандартах и привести к ним. Да и в целом непонятно можно ли сделать left success путём, а right — fail. Как-то в итоговом either логичнее бы смотрелось showError на втором месте: обычно нас интересует success путь прежде всего при чтении кода.

[L2jLiga]

Если взять в расчет, что все асинхронные функции node.js в качестве первого параметра в callback возвращают error, то выглядит логично.

[faiwer]

Найти бы ещё хоть 1 довольного этой сигнатурой человека :)

[yeputons]

Кроме того, исключения загрязняют код. Мы не будем здесь подробно обсуждать функциональную чистоту. Но давайте рассмотрим один маленький аспект функциональной чистоты: ссылочную прозрачность. Ссылочно-прозрачная функция всегда возвращает один и тот же результат для конкретного входа. Но для функций с исключениями мы не можем такого сказать. В любой момент они могут выдать исключение вместо возврата значения. Это усложняет логику.

Подмена понятий, имхо: поведение функции может не зависеть от внешнего состояния и она может выдавать исключения. Это тоже можно считать результатом, а не побочным эффектом. Для конкретного входа всегда один и тот же результат, нарушений ссылочной прозрачности я не вижу.

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

[Akademic]

Жутко. Интересно. Жутко интересно. Но на описании .ap(), мозг отказался дальше воспринимать. Надо попробовать через денёк вернуться. :)

[vba]

Та не, какая то каша получилась, автор взял да слил в одну лужу концепции Either и Railway Oriented Programming. В конце концов получилось что то нелепое. В RoP конечный продукт это продвинутая композиция функций а не непонятно что:

let process = step1 >>= step2 >>= step3