You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To improve the ergonomics of error handling, it would be nice if we could eliminate some union types from the error channel when explicitly handled in a catch block. Maybe we can simulate the symantics of ZIO.catchSome and ZIO.die:
importzio.*importzio.direct.*caseclassID()
caseclassPerson()
caseclassParseError()
caseclassDBError()
defparseId(s: String):IO[ParseError, ID] =???defgetPerson(id: ID):IO[DBError, Person] =???valt:IO[DBError, Person] = defer {
try {
valid= parseId("1").run
getPerson(id).run
} // ZIO[Any, DBError | ParseError, Person]catch {
casev: ParseError=>Person() // eliminate ParseError we return a subtype of Person (simulates ZIO.catchSome)casev: ParseError=>ZIO.die(???) // alternatively, terminate the fiber with a defect
}
}
The text was updated successfully, but these errors were encountered:
To improve the ergonomics of error handling, it would be nice if we could eliminate some union types from the error channel when explicitly handled in a catch block. Maybe we can simulate the symantics of
ZIO.catchSome
andZIO.die
:The text was updated successfully, but these errors were encountered: