When using `Either.catch()` I find myself wanting to treat it like `either {}` and use various DSL ...

# arrow

[Erik Dreyer]

When using Either.catch() I find myself wanting to treat it like either {} and use various DSL methods provided by Raise inside the catch() function. Since it doesn't provide that context, is this the correct way?

either {
    Either.catch() { ... }.bind()
}

[Youssef Shoaib [MOD]]

This is correct yes!
result builder does something similar btw, so this might be a good definition for a util:

result(block).fold(::Right, ::Left)

[simon.vergauwen]

Yes, that’s the correct way. Only couple days ago we had a similar question, https://kotlinlang.slack.com/archives/C5UPMM0A0/p1749141591846199

I guess it’s time to add a section to the docs, or would this warrant an additional builder? 🤔

[Youssef Shoaib [MOD]]

I think an Either.catching or similarly-named builder might be warranted here, implemented in a similar way to result {} (i.e. using fold)

[simon.vergauwen]

We should collect some use-cases because it seems everyone is doing something slightly different so providing a common DSL might be tricky.

@Erik Dreyer do you work with EitherThrowable, A, and you’re using which DSL functions? Mostly bind? I assume this is when interacting with some libraries or platform APIs? You potentially just skip the DSL and just use exceptions directly inside Either.catch. If you’re using i.e. ensure(false) { RuntimeException() } then you’re still paying the penalty of exceptions anyway. So you might as well just throw. If that’s not the case then the last 2 snippets from the linked thread might work nicely for you.

[Erik Dreyer]

This came up because I was reviewing some code and saw this gem in a PR:

private fun getToken(tokenId: UUID): Either<DataStorageError, Decrypted> = either {
    Either.catch {
        tokenDao.getToken(tokenId) ?: throw NoSuchElementException("Token not found for tokenId: $tokenId")
    }.mapLeft { exception -> handleTokenExceptions(exception)
    }.bind()
}

I get what it does, but I can't help feeling there's a less awkward way to express this.

maybe instead of this

tokenDao.getToken(tokenId) ?: throw NoSuchElementException("Token not found for tokenId: $tokenId")

you could do

ensureNotNull(tokenDao.getToken(tokenId)) { NoSuchElementException(...)}

and deal with it at the outer either {} block

[Erik Dreyer]

I'm told tokenDao.getToken(tokenId) can throw other exceptions, so we still need the Either.catch

[simon.vergauwen]

There is quite some redundant things going on 😅

So it throw NoSuchElementException("Token not found for tokenId: $tokenId") if getToken is null, but can getToken also throw?

If not, then it's probably just, tokenDao.getToken(tokenId).right() ?: handleTokenExceptions(?).

[Erik Dreyer]

for sure

[simon.vergauwen]

Any either { } with a single bind and nothing after it is probably redundant as well. This could also just be:

Either.catch {
    tokenDao.getToken(tokenId) ?: throw NoSuchElementException("Token not found for tokenId: $tokenId")
}.mapLeft { exception -> handleTokenExceptions(exception) }

[Erik Dreyer]

gracias