Hi all, I watched <@U0RM4EPC7>'s talk on Arrow 2 f...

# arrow

[Davio]

Hi all, I watched @simon.vergauwen's talk on Arrow 2 from KotlinConf 2023 and when the examples were shown of handling errors with context receivers it reminded me a lot of checked exceptions. So to me it felt somewhat ironic for Kotlin to ditch checked exceptions only to come full circle to another form of checked exceptions.

So I guess as much as we'd love to program like there are never going to be any errors, we can't hide from them so we might as well go the full distance in trying to make them first class citizens again

[simon.vergauwen]

Hey Dave,

A couple threads with interesting discussions on this topic, I've been planning to add this on the website as well.

https://kotlinlang.slack.com/archives/C5UPMM0A0/p1676923890785829?thread_ts=1674812558.690599&amp;cid=C5UPMM0A0

https://kotlinlang.slack.com/archives/C5UPMM0A0/p1678818702789269

[Davio]

Something which I might have overlooked is that in this case, the errors don't necessarily have to be (instances of) the Exception class with all the baggage that comes with them but could be simple data classes with as much or as little info as you'd like.

You could even have a generic wrapper ApplicationError<T> which exposes a value of type T

[simon.vergauwen]

Yes, exactly. What is also neat about Arrow’s Raise is that it’s an extensible DSL so it easily allows different wrappers, or errors types to work together.

Everything discussed here for outcome can work together with all the existing DSLs of Arrow.
https://kotlinlang.slack.com/archives/C5UPMM0A0/p1683655626676479

[CLOVIS]

It can be summarized as: checked exceptions in Java by themselves weren't really a bad idea, but they were badly executed (ugly syntax, no way to map on success without using a verbose try…catch , not supported in lambdas, the Exception super-class is massive, stack traces are expensive…)

It seems to me that Arrow 2.0's syntax is "checked exceptions done right".