Wait, with Arrow 2.0 we'll be able to have error management in constructors? :hushed:

# arrow

[CLOVIS]

Wait, with Arrow 2.0 we'll be able to have error management in constructors? 😯

[Youssef Shoaib [MOD]]

Doesn't Raise<SomeError> require the caller to be suspend though?

[simon.vergauwen]

No, Raise<SomeError> doesn't require suspension anymore.

[Youssef Shoaib [MOD]]

Oh cool, does it just work through exceptions or what? Because last I remember it all worked thru a custom coroutine continuation thing

[simon.vergauwen]

No, it has always worked though NoStackTrace exception otherwise it doesn't respect the rules of Kotlin Coroutines.

[simon.vergauwen]

All the design decisions are documented here, https://github.com/arrow-kt/arrow/pull/2797

[simon.vergauwen]

@CLOVIS, yes since you can annotate constructor with context receivers. So you can enforce a constructor being called from within a certain error handler.

[CLOVIS]

That's great, since they can't return Either

[CLOVIS]

Since it uses exceptions, what's the performance impact compared to plain old exception handling? Either etc were always presented as a more efficient approach.

[simon.vergauwen]

The performance penalty of exceptions comes from the stacktrace creation, but this can be disabled. By creating a specialised subclass of Throwable that avoids the creation of the stacktrace on construction.

The stacktrace creation is so expensive because it requires native calls and requires digging and interacting with the VM.

KotlinX Coroutines takes the same approach with JobCancellationException, so it's an established pattern for cancelling Kotlin Coroutines without the performance penalty.