Hi folks, in which cases would you recommend to us...

# arrow

[Laurent Thiebaud]

Hi folks, in which cases would you recommend to use arrow-kt typed errors for a web application?
Context: in the web application I'm working on, almost every method on any layer (except DB layer) returns a Either, which forces us to map errors, or to use for comprehension.
This looks good in some cases, but when a method cannot throw an exception, it looks over-complicated
Are there you some cases where that helps / some other where it is too much?

[Laurent Thiebaud]

Just discovered https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

[CLOVIS]

I always use typed errors [when I get the choice], if only because it allows me to have an exhaustive list of everything that can go wrong, and thus I can i18n'd all error messages.

[Ulrich Schuster]

It all depends on what you want to do with the errors. In our projects, we're trying to follow a simple pattern: If it is an error that shouldn't be (like, a bug, or underlying hardware failure that cannot be easily recovered), throw the error, end the current execution and provide a notification to ops, so we can fix the issue asap. If it is a "domain error" – something that is part of the business domain, use typed errors to report the issue back to the user. Here, the user might be some person sitting in front of a UI or some external API client code

[CLOVIS]

^ this is what most people do. In my case, I also have a generic error case for thrown exceptions as part of the domain errors, because I share code with the clients, and UI frameworks really don't like exceptions.

[Laurent Thiebaud]

It confirms what I read, thanks guys