Obsługa błędów

sealed abstract class UserError     extends Product with Serializable
sealed trait TokenResetError        extends UserError
sealed trait EmailRegistrationError extends UserError
sealed trait EmailConfirmationError extends UserError
sealed trait PasswordChangeError    extends UserError

object UserError {
  case object InvalidEmailOrPassword extends TokenResetError with PasswordChangeError
  case object InvalidEmailOrToken    extends EmailConfirmationError
  case object TokenExpired           extends EmailConfirmationError
  case object TokenNotExpired        extends TokenResetError
  case object AlreadyExists          extends EmailRegistrationError
  case object NotFound               extends PasswordChangeError
  final case class PasswordTooWeak(error: NonEmptyList[PasswordValidationError])
      extends EmailRegistrationError
      with PasswordChangeError
}

Problem: skomplikowana hierarchia

Obsługa błędów

trait UserService {
  import UserError._

  def changeEmailPassword[M[_]](uid: UID,
                                email: Email,
                                oldPassword: PlainPassword,
                                newPassword: PlainPassword)(
      implicit users: Users[M],
      ME: MonadError[M, PasswordChangeError]): M[User] = ???

  def registerUser[M[_]](email: Email, token: String)(
      implicit users: Users[M],
      ME: MonadError[M, EmailConfirmationError]): M[User] = ???

//...

}

Problem: monady obsługujące błędy (MonadError, EitherT) są inwariantne

MonadError[M, UserError] nie jest wspólną implementacją

Obsługa błędów

    findEmail(email)
      .flatMap(maybeEmail => ME.fromOption(maybeEmail, InvalidEmailOrPassword))
      .map(_.reset(plainPassword, confirmationTokenTtl).leftMap[TokenResetError] {
        case x => InvalidEmailOrPassword
        case y => TokenNotExpired
      })
      .rethrow

Problem: słabo z inferencją

Obsługa błędów

protected val createUser: Route = (post & entity(as[CreateUserRequest])) {
    onSuccess(...) {
        case Right(_) => complete(Accepted)
        case Left(e)  => completeWithError(e)
    }
}

def completeWithError[E](e: E)(implicit error: HttpErrorLike[E]) =
    complete(error.entity(e))

Idealnie by było tak jak powyżej:

Zwracamy jeden ogólny typ błędu i jakoś (jak?) automatycznie mapujemy go w kontekście HTTP.

 

Zalety: nie trzeba myśleć

Wady: zwracamy "za dużo"

Obsługa błędów

@implicitNotFound("Do not know how to map ${E} to the Http Response.")
sealed abstract class HttpErrorLike[E] {
  def entity(e: E): (StatusCode, JsObject)
}

object HttpErrorLike {

  private class WithReason[E](val statusCode: StatusCode, val errorCode: String)
      extends HttpErrorLike[E] {
    protected final val constantResponse = JsObject(Seq("reason" -> JsString(errorCode)))
    override def entity(e: E)            = statusCode -> constantResponse
  }

  def apply[E: ClassTag](statusCode: StatusCode): HttpErrorLike[E] =
    new WithReasonFromClass[E](statusCode)

  def notFound[E: ClassTag]            = apply[E](StatusCodes.NotFound)
  def conflict[E: ClassTag]            = apply[E](StatusCodes.Conflict)
  def unprocessableEntity[E: ClassTag] = apply[E](StatusCodes.UnprocessableEntity)

//...
}

Obsługa błędów

    implicit val invalidEmailOrPasswordLike: HttpErrorLike[InvalidEmailOrPassword.type] =
      unprocessableEntity
    implicit val alreadyExistsErrorLike: HttpErrorLike[AlreadyExists.type] = conflict
    implicit val invalidEmailOrTokenLike: HttpErrorLike[InvalidEmailOrToken.type] =
      unprocessableEntity
    implicit val tokenExpiredLike: HttpErrorLike[TokenExpired.type]       = unprocessableEntity
    implicit val tokenNotExpiredLike: HttpErrorLike[TokenNotExpired.type] = unprocessableEntity
    implicit val notFoundLike: HttpErrorLike[NotFound.type]               = notFound

To jakby działa, ale dalej nie możemy mapować dowolnego UserError tj. chcemy powiedzieć, że implicit dla UserError istnieje jeśli istnieje implicit dla każdej podklasy

Obsługa błędów

  import shapeless._

  implicit val cnilHttpErrorLike: HttpErrorLike[CNil] = new HttpErrorLike[CNil] {
    override def entity(e: CNil) = e.impossible
  }
  implicit def coproductHttpErrorLike[H, T <: Coproduct](
      implicit hErrorLike: HttpErrorLike[H],
      tErrorLike: HttpErrorLike[T]): HttpErrorLike[H :+: T] =
    new HttpErrorLike[H :+: T] {
      override def entity(e: H :+: T) =
        e.eliminate(hErrorLike.entity, tErrorLike.entity)
    }
  sealed abstract class GenericHttpErrorLike[A] extends HttpErrorLike[A] {
    type Repr <: Coproduct

    def toGenericRepr(a: A): Repr
    def reprErrorLike: HttpErrorLike[Repr]

    override final def entity(e: A) = reprErrorLike.entity(toGenericRepr(e))
  }
  implicit def genericHttpErrorLike[ADT, Repr0 <: Coproduct](
      implicit generic: Generic.Aux[ADT, Repr0],
      hierarchy: HttpErrorLike[Repr0]): GenericHttpErrorLike[ADT] =
    new GenericHttpErrorLike[ADT]() {
      override type Repr = Repr0

      override def toGenericRepr(a: ADT) = generic.to(a)
      override val reprErrorLike         = hierarchy
    }

  def hierarchy[ADT](implicit gen: GenericHttpErrorLike[ADT]): HttpErrorLike[ADT] = gen

Obsługa błędów

    implicit val userError: HttpErrorLike[UserError] = HttpErrorLike.hierarchy[UserError]

Behold!

Obsługa błędów

protected val createUser: Route = (post & entity(as[CreateUserRequest])) {
    onSuccess(...) {
        case Right(_) => complete(Accepted)
        case Left(e)  => completeWithError(e)
    }
}

Zalety: zwracamy jeden ogólny typ błędu i jakoś (jak?) automatycznie mapujemy go w kontekście HTTP

Iterators Lightning Talk

By Marcin Rzeźnicki

Iterators Lightning Talk

  • 979