В статью об обработке ошибок добавлено примечание о Rich Errors

Author: d-r-q

content/docs/patterns/operations-impl/error-handling.adoc

@@ -14,20 +14,26 @@ weight: 500
 
 Официального руководства по обработке ошибок в Kotlin не существует, но есть https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07[пост] Романа Елизарова (бывшего ведущего дизайнера Kotlin), который можно считать полуофициальным руководством.
 В этом посте Елизаров рекомендует использовать исключения только для логических ошибок (тех, что программисты должны исправить в коде) и ошибок ввода-вывода (тех, что девопсы должны исправить в инфраструктуре или конфигурации).
-А для всего остального использовать link:++{{<ref "/docs/terminology/functional-error-handling">}}++[ функциональный (ака типизированный)] подход к обработке ошибок.
+А для всего остального использовать link:++{{<ref "/docs/terminology/functional-error-handling">}}++[функциональный (ака типизированный)] подход к обработке ошибок.
 
-Но в отличие от "прирождённых" функциональных языков с типами (Haskell, Scala, F#), Kotlin-у не хватает целого ряда инструментов для эффективной работы в таком стиле:
+Но в отличие от "прирождённых" функциональных языков с типами (Haskell, Scala, F#), в Kotlin 2.2 не хватает целого ряда инструментов для эффективной работы в таком стиле:
 
 . лаконичного синтаксиса для типов-сумм;
 . встроенной монады для ошибок;
 . синтаксической поддержки работы с монадами.
 
-В результате работа с ошибками в функциональном стиле на Kotlin-е становится довольно громоздкой.
+В результате работа с ошибками в функциональном стиле на Kotlin становится довольно громоздкой.
 
 Кроме того функциональный стиль работы с ошибками не интегрируется с основными и даже нативными для Kotlin фреймворками и библиотеками.
 В частности ни Spring, ни Exposed не откатят транзакцию при возврате стандартного Result.failure из транзакционного метода/блока, не говоря уж о кастомном ADT.
 Как и в корутинах возврат Result.failure из корутины-потомка не приведёт к автоматическому останову корутин-сиблингов.
 
+[NOTE]
+====
+Судя по всему, https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md[Kotlin Rich Errors] решат проблему эргономики функционального подхода к обработке ошибок и тогда можно будет рассмотреть его более  активное применение.
+Однако надо ещё посмотреть как такие ошибки будут обрабатываться в библиотеках и фреймворках.
+====
+
 Ещё одной проблемой функционального подхода к обработке ошибок в Kotlin является то, что в случае процедур (методов и функций, возвращающих Unit) ошибку проще проигнорировать, чем обработать.
 
 Наконец, в Clojure (функциональном языке) выброс исключения https://www.daveliepmann.com/articles/idiomatic-clojure-errors.html[является идиоматичным] способом обработки ошибок, а Скот Влашин (автор термина ROP и один из активных пропагандистов функциональной архитектуры) https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/[рекомендует] исключения для быстрого завершения операции.