Что такое монадическая обработка ошибок?

Question

[Eugene523]

Что такое монадическая обработка ошибок? И почему это круто? К примеру в языке Go нет функциональности try-catch-finally. Как я понимаю это позаимствовано из функциональных языков. Объясните для человека не знакомого с функциональным программированием, в чем плюс отсутствия try-catch-finally.

Comments

[mayton2019]

Подписался на топик.

Answer 1

[uvelichitel]

Errors are values.
Don't just check errors, handle them gracefully.
(c) Rob Pike https://go-proverbs.github.io/

Answer 2

[Александр Скуснов]

Наглядные картинки в "железнодорожно-ориентированном" программировании.

Answer 3

[alfss]

Посмотрите причину создания и основные требования к языку

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

Простая и регулярная грамматика. Минимум ключевых слов, простая, легко разбираемая грамматическая структура, легко читаемый код.

Простая работа с типами. Типизация должна обеспечивать безопасность, но не превращаться в бюрократию, лишь увеличивающую код. Отказ от иерархии типов, но с сохранением объектно-ориентированных возможностей.

Отсутствие неявных преобразований.

Answer 4

[mayton2019]

Интересно обратываются ошибки I/O в Rust. Там такой синтаксис что ты не можешь получить результат не обработав ошибку. Является ли это монадической схемой? ХЗ.

use std::fs;

fn main() {
    let data = fs::read_to_string("/etc/hosts").expect("Unable to read file");
    println!("{}", data);
}

В других языках можно как-то проскочить между капелек дождя. Просто не делать секцию catch(exception) а здесь компиллятор просто не соберет код без except().

Есть еще другой более красивый кейс с Rust но я его не найду никак.

Comments

[Василий Банников]

Более красивый вариант будет через вопросительный знак.
Но вообще да, Result в расте - самая настоящая монада.

Answer 5

[Василий Банников]

Монадическая обработка ошибок - это когда для представления результата операции, которая может закончиться ошибок, используется монада. Например Either (aka Result).

В Go хоть и нет try-catch, но и монадической обработки ошибок тоже нет.

Главнаый смысл монад в том, что ты не можешь напрямую молча её распаковать.
А ещё есть функция map() с помощью которой можно безопасно обработать успешный результат.

Хорошие примеры языков с такой системой - Haskell, F#, Ocaml, Rust.

Также советую посмотреть на railroad oriented programming, ссылку на которую скинул Александр Скуснов.

Answer 6

[Vitsliputsli]

Что такое монадическая обработка ошибок? И почему это круто?

Очевидно использование монад для обработки ошибок. "Монада – это просто моноид в категории эндофункторов. Функтор – это гомоморфизм между категориями. А эндофунктор – это просто функтор, отображающий категорию на саму себя. "
По-моему уже этого достаточно, чтобы ответить на 2ой вопрос.

Объясните для человека не знакомого с функциональным программированием, в чем плюс отсутствия try-catch-finally.

Монада - это попытка обойти ограничения функционального программирования, выполнять последовательные операции, т.е. делать то, что делается при императивном подходе из коробки. Т.е. монада специфична для функционального, а try-catch-finally для императивного, и последний в первый никак не запихнуть, поэтому - монада.
Нет принципиальной разницы в этих методах обработки ошибок, ошибки идут отдельным потоком, разница лишь когда будет вызван обработчик.
Насколько я знаю, для монад есть еще один аргумент - это убирание обработки ошибок "под капот", т.е. мы видим решение только тест-кейса основной бизнес-логики, а тест-кейсы ошибок скрыты. Если говорить про ООП, там это не проблема, при подобном структурировании обработчик ошибок будет именно там, где и должен быть, к примеру, если мы говорим о "File not found", то в классе отвечающем за инфраструктуру и в бизнес-логике мы его не увидим. Кроме того, мы можем задать общий обработчик, а не писать всюду try catch. Что касается процедурного подхода, то наверное абсолютно все спрятать не получится, но если мы в 22 году пишем процедурно, у нас приоритет не структуризация, а производительность и здесь уже другие критерии.

Comments

[mayton2019]

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

[Vitsliputsli]

mayton2019, мы используем абстракции не ради самих абстракций. Использование абстракций - это попытки обобщенного программирования, для возможностей расширения кода основываясь на универсальных решениях, дабы не натыкаться на жесткую специализированность. И, согласен, далеко не всегда они нужны, фанатичное следование приведет к высокой раздробленности кода, это как Чистый Код Мартина - вроде бы очень универсально, но на практике не применимо.

[mayton2019]

Vitsliputsli, Мартин? Мне кажется старик весьма умерен. Я читал его советы по оформлению кода. Они такие очевидные как - одевать шапку зимой например. Можно его особо и не читать. Так. Кодинг в ентерпрайзе приводит к пониманию тех-же истин. И не через книжные тезисы а просто через пинки и подзатыльники от коллег.

Ну а для фрилансера Мартин наверное бесполезен.

[Vitsliputsli]

mayton2019, да, но у него есть рекомендации создавать отдельные функции на каждый чих, я про это.

[mayton2019]

Vitsliputsli, это в контексте тезисов Go?

A little copying is better than a little dependency.

Я пожалуй соглашусь. Я лет 5 назад только стал использовать lambda-expressions
и вот если в таком разрезе - то уж лучше встроенная функция чем выделенная в отдельный модуль и опубликованная где-то в обозримой вселенной. Потом все равно ее хрен найдешь. Даже в своих собственных репо.

[Vitsliputsli]

mayton2019, Мартин примеры давал в ООП на Java, так что не в контексте Go. И там, насколько помню, вплоть, что отдельные команды засовываем в отдельные методы. Это действительно бывает оправдано порой, но я лучше в таких ситуациях перепишу все обращения, чем в остальных 98% случаев заранее наделаю множество методов. Да, конечно, не совсем соблюдаю open/closed принцип, но по мне это меньшее зло.

[mayton2019]

Vitsliputsli, читая описание Go - меня не покидало ощущение что это - оружие пролетариата. Тоесть язык который изначально был создан для того чтобы херачить много кода не мудрствуя лукаво. Пока джентльмены из Глазго сидят в Хаскеле и думают как лаконичнее сделать функцию, пролетариат - херачит тонны кода. Под флагом хомяка.

Но при этом в Go есть классные штуки как Goroutines. Легковесные потоки который зайдут в Java еще не скоро. Есть channels, которые тоже вроде как объекты language-level. Вобщем я смотрю на Go с интересом. Тем более что мне по работе приходится много бодаться с девопсами. А эта область - близка к Go/Python скорее чем к Rust/Haskell. Вангую для себя неизбежное столкновение в этим языком.

[Vitsliputsli]

mayton2019, язык - это просто инструмент, если не делать из языка культ, то разработчик берет тот инструмент, который наиболее удобен, знаком, доступен, лучше поддерживается, совместим и использует его здесь и сейчас. По-хорошему разработка должна вестись не на языке, а с его помощью. Есть объективные причины для выбора языка - производительность и скорость разработки. Есть менее значимые, но которые почему-то используют для дефирамбов в адрес того или иного языка. Что-то вроде: "вот здесь лаконичнее, чем там". Или "здесь, меньше возможностей совершить ошибку". Они субъективны, потому что очень проблематично определить возможность совершения ошибки, а лаконичность может напрочь убивать читаемость и т.п..
Я, конечно, тоже субъективно сужу, но Go и Python встречаю повсеместно, а Rust и Haskell днем с огнем не сыщишь. И как коммерческий разработчик, я делаю выбор в пользу первых. Но, для академических исследований, выбор может быть другим. Это не значит, что в коммерческой разработке никто не берет ничего нового, буть так мы бы Go не увидели, но предпочтут знакомый инструмент, с известными слабостями, чем претенциозный новый, где подводные камни еще не найдены.

Пока джентльмены из Глазго сидят в Хаскеле и думают как лаконичнее сделать функцию, пролетариат - херачит тонны кода.

Именно так, пока кто-то изобретает лучший мир, кто-то должен делать работу, нужную здесь и сейчас. Это не значит, что последние бестолковые чернорабочие. Просто, кто-то штроборезом не может ровно сделать штробу, а кто-то за не имением оного и болгаркой отлично ее выпилит.