Hi All, another question: I'm using `Either` like ...

# arrow

[Xuc Xiem]

Hi All, another question: I'm using Either like this:

fun f(): Either<Exception, A> = try {
  // do something
  Either.right(a)
}
catch (e: Exception) {
  Either.left(e)
}

Is that the correct way to use Either ? Is there anything more suitable than Either for that purpose (wrapping a value and catching all exceptions)?

[raulraja]

Either.catch { } //inside suspend

[streetsofboston]

Catching all exceptions is usually not a good idea. You’d usually want to catch non-fatal exceptions and handle them. Fatal exceptions should crash your app (fast failure).

Also, I tend to not use Exception as the left-type/error-type. Try to model your errors, by examining and translating the caught exception into a (data) class that represents the error you want to return to the caller.

return try {
    Either.Right(someResult(...))
} catch (e: SpecificException) {
    Either.Left(MyError.from(e))
}

[streetsofboston]

Catching any exception in suspend fun can have bad side-effect because you could catch a CancellationException that way, which then gets ignored (not re-thrown) and will break the Structured Concurrency framework.

[raulraja]

yes, for the record Either.catch only handles non fatal exceptions that are safe to capture https://github.com/arrow-kt/arrow-core/blob/5b8ca8b74d5c130987c77aedad693849a9d73f72/arrow-core-data/src/main/kotlin/arrow/core/Either.kt#L901

[raulraja]

@streetsofboston I believe the new Arrow Fx Coroutine lib currently in PR does not face that problem since we are not dealing with exceptions there but @simon.vergauwen can confirm better than I do.

[simon.vergauwen]

Catching any exception in suspend fun can have bad side-effect because you could catch a CancellationException that way, which then gets ignored (not re-thrown) and will break the Structured Concurrency framework.

That is correct but it’s a problem introduces by KotlinX not something that inherit-ally comes from Java or Kotlin itself.

[simon.vergauwen]

We never catch fatal-exceptions in Arrow, and if we do so we consider that a bug.

[streetsofboston]

@raulraja BTW: I really enjoyed your KUG Chicago talk you recently gave about type-proofs

[streetsofboston]

Yes, catching the CancellationException being bad is something unique to kotlinx-coroutines. But it easy to make that mistake there and can have bad side-effects….

But my main point is that I think that is it better to not return exceptions as error-types (left-types) but your own model error-types instead.

[raulraja]

thanks @streetsofboston we showed more of that at kotliners today, hope the video comes live soon

[streetsofboston]

I saw the video as a recording at a later time, not live during your talk. The video is available to watch for anyone, i think

[raulraja]

do you have a link? Can’t find it

[streetsofboston]

Hard time finding it back, it wasn’t on youtube….

[streetsofboston]

@raulraja Not sure why it didn’t show up in my history, but the chicago talk is right on the 47 Degrees Youtube site:

https://www.youtube.com/watch?v=lK80dPcsNUg▾