Worth looking at:

https://gist.github.com/quelgar/d383cd960d781fe72a1564203c280a03

As it addresses many topics important to consider in this phase of the documentation.

Worth looking at:

https://gist.github.com/quelgar/d383cd960d781fe72a1564203c280a03

As it addresses many topics important to consider in this phase of the documentation.

Great article! Yes, I noticed that from your tweets.

While documenting union types on ZIO's error parameter, a question popped into my head. Why the compiler does not infer the proper type for myApp? It should be ZIO[Any, FooError | BarError, Unit], is this true?

// Two unrelated errors without having a common supertype (e.g. FooBarError) or the Throwable/Exception supertype
trait FooError
trait BarError

// Why the compiler doesn't infer the error type as `FooError | BarError`?
val myApp: ZIO[Any, Object, Unit] = for {
  _ <- ZIO.fail(new FooError {})
  _ <- ZIO.fail(new BarError {})
} yield ()

@jdegoes @adamgfraser

Update: I found that it is the inherent behavior of the Scala 3's type system related to the LUB algorithm and is not related to ZIO itself.

Hi @khajavi , could you please add some description of resurrect method, since it's closely related to orDie? Here's how I understand the usage of orDie + resurrect:

Sometimes we want to turn a ZIO[R, E, A] into ZIO[R, Nothing, A]. An unexpected database failure can be an example of this. Let's say I'm using MongoDB with mongo-scala-driver. mongo-scala-driver returns scala.concurrent.Future which I need to somehow turn into ZIO[R, Nothing, A], because callers of data access layer don't need to know about unexpected Mongo failures. I call Task.fromFuture(...).orDie to get rid of the Throwable.

Somewhere in my application I have a generic top level handler which does something like

.resurrect
.catchAll {
  case unexpected: Throwable => log.error(unexpected) *> ZIO.succeed(InternalServerError)
}

Is this the right usage of resurrect? I think it should be documented. I'm having a hard time trying to persuade my coworkers to use orDie + resurrect. They're concerned about killing the fiber. I wonder how resurrect works internally, when ZIO is run. Is it something like

catch {
  case ex: InterruptedException => ...
}

?

Also, is it possible to add a section saying something like "don't be lazy, encode errors with ADTs instead of using Throwable as an E"? I'm currently working on a codebase where everything is a ZIO[R, Throwable, A] and for typed errors something like ZIO[R, Throwable, Either[DomainError, A]] is used 😃

@edubrovski
Thank you for your note, helping the documentation becomes better.

I'm not sure this is a use case for resurrect, if those errors are unexpected errors, why not use ZIO#catchAllDefect?

@khajavi,
thanks for pointing me to catchAllDefect, I didn't know it existed. I think it makes sense to add a couple of lines about catchAllDefect then. Currently the doc doesn't explain how to actually handle defects after we create them with orDie. In most real life cases we want to handle them, not simply dump them to stdout. Even if a defect is completely unexpected and we're letting a piece of code crash, we still might want to:

• log it nicely by sending it to a log aggregator like Splunk
• send an email alert to developers
• display a nice "unexpected error" message to the user
• etc.

@khajavi

In theory, if we changed flatMap to return E1 | E2, then it should work. This is probably worth thinking about for 2.0.

@khajavi Are you done with this one?

@jdegoes
There are still a few topics to cover, but it is almost done.
If you have any thoughts on this, please let me know.

@jdegoes
This work is ready for your review.