Hi all, this might be a strange question, but in o...

# arrow

[Davio]

Hi all, this might be a strange question, but in our project we are only using Arrow for typed error handling and, this might be an unpopular opinion, the eithers don't really improve the code. I'm anxiously waiting for context receivers to be finalized to use it.

Now, using Arrow only for error handling seems kind of limited, what other use cases, mostly those found in microservices, would Arrow be a good fit for?

[stojan]

• concurrency on top of coroutines -> https://arrow-kt.io/learn/coroutines/parallel/
• resource safety -> https://arrow-kt.io/learn/coroutines/resource-safety/
• resilience -> https://arrow-kt.io/learn/resilience/intro/

[Stylianos Gakis]

the eithers don't really improve the code as opposed to what?

[Davio]

Well as opposed to just documenting the code with @throws and dealing with the runtime exceptions I guess

[Stylianos Gakis]

And having to catch exceptions everywhere, while also making sure not to catch and swallow CancellationExceptions?

[JasonB]

the DSL helps a lot with the readability, if you haven't used that

[Ties]

https://blog.jdriven.com/2023/07/error-handling/ I wrote a bit of a blog about error handling. It kinda depends on your use case if either improve your code or not. If for example you only have non recoverable errors, runtime exceptions might be better. Do keep in mind that functions throwing a runtime exception effectively return an Either<Throwable, T> but it's just not documented. Also, if this happens to be in your code base, try to avoid having an Either as an input to a function (that problem can be fixed using either.map and then call the function). That might help as well

[mitch]

@Davio it’s an interesting discourse. There are pros and cons with regards to cognitive complexity, maintainability as well as domain modelling. Types and typed error handling, or rather context and domain boundaries are simply tools in your toolbox that, when utilized appropriately, can improve not only cognition, but also maintainability of a codebase and agility of teams.

I’ve recently wrote a comparative study on various errors handing strategies in Kotlin, their impact on maintainability, readability, as well as their pros and cons. https://betterprogramming.pub/typed-error-handling-in-kotlin-11ff25882880

When you mentioned “it’s not more useful than e.g. runtime exception”, Sonar did show that cognitive complexity of exceptions are not exactly bad. However, as @Ties rightly emphasized, the most painful was the lack types or rather undocumented behaviour. It really hurts when the codebase grows, especially when there isn’t a good technical leadership around domain modelling. We had a pretty sizeable service written in this style that we had to unfortunately rewrite due to maintainability issues.

In our company we have a large Kotlin gradle monorepo leveraging typed error handling approach. Having worked with large teams of varying experience, types and the simplicity that Arrow provides tremendously enhance our ability to deliver value with greater agility and confidence. It’s fascinating to listen to first time contributors having discussions about something along the lines of “oh i need to update my design, there’s a gap because we need handle these failure cases”

[Davio]

Thanks for your input, I guess in some instances it's also a case of preference or what kind of patterns you use