I'm looking through this <example> and wonder if Exception handling is intentionally omitted here (a...

# arrow

[Srki Rakic]

I'm looking through this example and wonder if Exception handling is intentionally omitted here (all the way down the stack)? My assumption is that the function is defined as suspend because it is making a network call (not pure), but I'm curious what would be the recommended approach to handling exceptions.

[raulraja]

hi @Srki Rakic, you can use Either.catch { } then toValidatedNel

[raulraja]

if you want to handle exception resulting from the network call and make them part of the returned value

[raulraja]

One of your error cases for validation may look like.

data class InvalidDue2Network(t: Throwable): YourBaseError()

[raulraja]

so you can go from the network throwable to your model before exiting the function.

[Srki Rakic]

Thank you. That's what I typically do with those type of calls Either.catch { }.mapLeft { } , but seeing the example I was wondering if that is not the best/recommended pattern for handling functions with side-effects.

[simon.vergauwen]

Either.catch { }.mapLeft { } is a great pattern to use. Typically you want to make sure that your error type keeps a reference to the Throwable so you have that information for later inspection.

Something like:

data class DatabaseError(val original: Throwable)

val user: Eithre<Throwable, User> = 
  Either.catch {
     userFromDatabase()
  }.mapLeft(::DatabaseError)

[Srki Rakic]

🙌