Although the idea and most of the members stayed the same, some of the changes are breaking changes in 2.x version. Therefore, a major version update has been made. Following changes are documented in Scala format but the same changes are made for Kotlin and Java with the same idea.
e-core module is removed. It was a common Java module to share code between Scala, Kotlin and Java modules but it didn't provide enough value and made definitions more complex than they needed to be. With 2.x; e-scala, e-kotlin and e-java are main modules instead of implementations of e-core.
The function of E has not changed but its internal representation of an error is changed a bit. Following are field changes in E type.
| Change | 1.x | 2.x |
|---|---|---|
name field |
Type: StringDefault value: "" (empty string) |
Type: Option[String]Default value: None |
message field |
Type: StringDefault value: "" (empty string) |
Type: Option[String]Default value: None |
code field |
Type: IntDefault value: 0 |
Type: Option[Int]Default value: None |
cause field |
Represents an external cause Type: Option[Throwable]Default value: None |
Represents multiple external causes as E Type: List[E]Default value: List.empty |
data field |
Type: Map[String, String]Default value: Map.empty |
(No changes) |
time field |
(Does not exist) | Represents the time error occurred as milliseconds since Epoch, addressing #26 Type: Option[Long]Default value: None |
| Field order in constructor | name, message, code, cause, data | code, name, message, causes, data, time |
Maybe type in 1.x is now called EOr. Although it looks like a harder name to work with, it provides a better meaning and it is shorter. In order to understand what this type is, the only thing to know is the fact that "errors are represented as E". When used with a type parameter as EOr[String], it both reads and means that the value will either be an E or a String. In Scala, there is even a type alias that provides this exact syntactic sugar, where you can replace EOr[String] with E or String if you wish.
The implementations (i.e. Success and Failure) and members of EOr in 2.x are almost the same as Maybe in 1.x. Here are the differences:
| Change | 1.x | 2.x |
|---|---|---|
| Accessor values are renamed | eOpt: Option[E] and valueOpt: Option[A] |
error: Option[E] and value: Option[A] |
| Check values are renamed | isSuccess: Boolean |
hasValue: Boolean and its counterpart hasError: Boolean is added |
| Error mapping | (Doesn't exist) | mapError and flatMapError methods are added to map according to the error, not the value |
| Extensions are changed | Extensions (i.e. toMaybe methods for several types) come from e.scala.implicits) |
Extensions come from e.scala and are named toEOr (because they are invoked on values) |
JsonStringEncoder is removed and its behavior is embedded in E and EOr by default.
Due to e-core being removed, Decoder, Encoder and their combination Codec changed slightly. They are not specialized for E or EOr. They are just definitions of decoding and encoding things.
| 1.x | 2.x |
|---|---|
e.scala.Codec[A] where A is both source and target |
e.scala.codec.Codec[S, T] where S is source and T is target |
e.scala.Decoder[IN] where IN is input |
e.scala.codec.Decoder[-I, +O] where I is input and O is output |
e.scala.Encoder[OUT] where OUT is input |
e.scala.codec.Encoder[-I, +O] where I is input and O is output |
Their implementations are in separate modules such as e-circe or e-gson and they provide instances of these for E and EOr.