Add ZValidation#toException

[sideeffffect]

No description provided.

[adamgfraser]

Hmmm, I'm inclined to think we should just implement getOrElse.

There isn't a generic way to convert a collection of E values into a Throwable. We're seeing that just discussing the implementation of these methods. Should it be an IllegalArgumentException or not? Should it include the log? Should it use suppressed exceptions?

Since there isn't a generic way to do it we should just provide operators like fold or getOrElse that allow users to do it as easily as possible.

[sideeffffect]

Sure there is 😃 ZValidationFailureException is 100% the same thing as ZValidation.Failure, only a subtype of Exception, so it has log and whether it is IllegalArgumentException or not is immaterial. The whole point of it is to make it easy to throw. We can think of it as an interop with the wider JVM world.

I have extensive experience with Validated from cats, where I needed a functionality like this fairly often and had to do it myself, which was annoying, so I wanted to improve ZIO Prelude to make it more appealing compared to the competition. If we don't provide users with functions like toException or getOrHandleException, they will have to write more boilerplate code, I don't think I've been the only one with such use case.

The toExceptionWithCause variant is just a cherry on top. It builds on top of the basic variant and gives the user the benefit that the "JVM interop" is improved, but works only if Es are Throwables. I think this extension of the basic variant is worthwhile and will be used in practice, not only because people make their domain errors subtypes of Exception.

Good point about the getOrElse, I've added it. (We already have fold.)

[adamgfraser]

Hmmm. My experience has been that organizations that use Validation also create their own error types when they do need to throw exceptions, though I'm sure practices vary. This seems somewhat ad hoc to me and I don't see it as being so important that we need to do this as opposed to just letting people throw whatever errors they want to based on the information contained in Validation. So I am mildly 👎 on this.

[sideeffffect]

Sometimes it's just easier to throw the exception you're given, without necessarily creating a custom exception yourself for such situation. Sometimes creating a custom exception class is just overkill. With this PR merged, ZIO Prelude would have a choice to do that. Typically, it would be useful in situations where an error is really unexpected and happens only in case of a severe failure.
Example where I would find this helpful is this: https://github.com/Idealiste-cz/ideal-voting-backend/blob/e27c04a/ideal-voting-server/src/main/scala/cz/idealiste/idealvoting/server/Db.scala#L79

But I've create a smaller PR, hopefully less controversial, with parts of functionality of this one:
#610