Cómo manejar los errores en la JVM más rápido

Hay varias formas de manejar errores en lenguajes de programación:

• excepciones estándar para muchos lenguajes (Java, Scala y otras JVM, python y muchos otros)
• códigos de estado o banderas (Go, bash)
• Varias estructuras de datos algebraicos, cuyos valores pueden ser resultados exitosos y descripciones de errores (Scala, Haskell y otros lenguajes funcionales)

Las excepciones se usan ampliamente, por otro lado, a menudo se dice que son lentas. Pero los oponentes de un enfoque funcional a menudo apelan al rendimiento.

Recientemente, he estado trabajando con Scala, donde puedo usar igualmente las excepciones y varios tipos de datos para el manejo de errores, por lo que me pregunto qué enfoque será más conveniente y más rápido.

Inmediatamente descartaremos el uso de códigos y marcas, ya que este enfoque no se acepta en los idiomas JVM y, en mi opinión, es demasiado propenso a errores (lo siento por el juego de palabras). Por lo tanto, compararemos las excepciones y los diferentes tipos de ADT. Además, el ADT puede considerarse como el uso de códigos de error en un estilo funcional.

ACTUALIZACIÓN : se añaden excepciones sin trazas de pila a la comparación

Concursantes

• Buenas viejas excepciones
• Excepciones sin seguimiento de pila, ya que llenar un seguimiento de pila es una operación muy lenta
• Try[T] = Success(value: T) | Failure(exception: Throwable) Try[T] = Success(value: T) | Failure(exception: Throwable) : las mismas excepciones, pero en un contenedor funcional
• Either[String, T] = Left(error: String) | Right(value: T) Either[String, T] = Left(error: String) | Right(value: T) : un tipo que contiene el resultado o una descripción del error
• ValidatedNec[String, T] = Valid(value: T) | Invalid(errors: List[String]) ValidatedNec[String, T] = Valid(value: T) | Invalid(errors: List[String]) : un tipo de la biblioteca Cats , que en caso de error puede contener varios mensajes sobre diferentes errores (no List usa List , pero no importa)

NOTA: en esencia, las excepciones se comparan con el seguimiento de la pila, sin y ATD, pero se seleccionan varios tipos, ya que Scala no tiene un enfoque único y es interesante comparar varios.

Además de las excepciones, las cadenas se usan para describir errores, pero con el mismo éxito en una situación real, se usarían diferentes clases ( Either[Failure, T] ).

El problema

Para probar el manejo de errores, tomamos el problema del análisis y la validación de datos:

 case class Person(name: String, age: Int, isMale: Boolean) type Result[T] = Either[String, T] trait PersonParser { def parse(data: Map[String, String]): Result[Person] } 

es decir tener un Map[String, String] datos sin procesar Map[String, String] necesita obtener Person o un error si los datos no son válidos.

Tirar

Una solución para la frente usando excepciones (en adelante daré solo la función de person , puedes ver el código completo en github ):
Throwparser.scala

  def person(data: Map[String, String]): Person = { val name = string(data.getOrElse("name", null)) val age = integer(data.getOrElse("age", null)) val isMale = boolean(data.getOrElse("isMale", null)) require(name.nonEmpty, "name should not be empty") require(age > 0, "age should be positive") Person(name, age, isMale) } 

aquí string , integer y boolean validan la presencia y el formato de tipos simples y realizan la conversión.
En general, es bastante simple y claro.

ThrowNST (Sin seguimiento de pila)

El código es el mismo que en el caso anterior, pero las excepciones se usan sin un seguimiento de pila siempre que sea posible: ThrowNSTParser.scala

Prueba

La solución detecta excepciones antes y permite combinar los resultados a través de for (que no debe confundirse con bucles en otros idiomas):
TryParser.scala

  def person(data: Map[String, String]): Try[Person] = for { name <- required(data.get("name")) age <- required(data.get("age")) flatMap integer isMale <- required(data.get("isMale")) flatMap boolean _ <- require(name.nonEmpty, "name should not be empty") _ <- require(age > 0, "age should be positive") } yield Person(name, age, isMale) 

un poco más inusual para un ojo frágil, pero debido al uso de for , es muy similar a la versión con excepciones, además, la validación de la presencia de un campo y el análisis del tipo deseado se producen por separado ( flatMap se puede leer aquí and then )

Ya sea

Aquí el tipo Either está oculto detrás del alias Result ya que el tipo de error es fijo:
EitherParser.scala

  def person(data: Map[String, String]): Result[Person] = for { name <- required(data.get("name")) age <- required(data.get("age")) flatMap integer isMale <- required(data.get("isMale")) flatMap boolean _ <- require(name.nonEmpty, "name should not be empty") _ <- require(age > 0, "age should be positive") } yield Person(name, age, isMale) 

Dado que el estándar Either como Try forma una mónada en Scala, el código salió exactamente igual, la diferencia aquí es que la cadena aparece aquí como un error y las excepciones se usan mínimamente (solo para manejar errores al analizar un número)

Validado

Aquí, la biblioteca Cats se usa para no obtener lo primero que sucedió, sino todo lo posible (por ejemplo, si varios campos no son válidos, el resultado contendrá errores de análisis para todos estos campos)
ValidatedParser.scala

  def person(data: Map[String, String]): Validated[Person] = { val name: Validated[String] = required(data.get("name")) .ensure(one("name should not be empty"))(_.nonEmpty) val age: Validated[Int] = required(data.get("age")) .andThen(integer) .ensure(one("age should be positive"))(_ > 0) val isMale: Validated[Boolean] = required(data.get("isMale")) .andThen(boolean) (name, age, isMale).mapN(Person) } 

este código ya es menos similar a la versión original con excepciones, pero la verificación de restricciones adicionales no está divorciada de analizar los campos y todavía recibimos varios errores en lugar de uno, ¡vale la pena!

Prueba

Para las pruebas, se generó un conjunto de datos con un porcentaje diferente de errores y se analizó en cada una de las formas.

Resultado en todos los porcentajes de errores:

Con más detalle, con un bajo porcentaje de errores (el tiempo es diferente aquí desde que se utilizó una muestra más grande):

Si alguna parte de los errores sigue siendo una excepción con el seguimiento de la pila (en nuestro caso, el error de analizar el número será una excepción que no controlamos), entonces, por supuesto, el rendimiento de los métodos de manejo de errores "rápidos" se deteriorará significativamente. Validated ve especialmente afectado, ya que recopila todos los errores y, como resultado, recibe una excepción lenta más que otros:

Conclusiones

Como mostró el experimento, las excepciones con los rastros de la pila son realmente muy lentas (¡el 100% de los errores son la diferencia entre Throw y Either más de 50 veces!), Y cuando prácticamente no hay excepciones, usar ADT tiene un precio. Sin embargo, el uso de excepciones sin trazas de pila es tan rápido (y con un bajo porcentaje de errores más rápido) como ADT, sin embargo, si tales excepciones van más allá de la misma validación, no será fácil rastrear su fuente.

En total, si la probabilidad de una excepción es superior al 1%, las excepciones sin trazas de pila funcionan más rápidamente, Validated o regulares. Either casi tan rápida. Con una gran cantidad de errores, Either puede ser un poco más rápido que Validated solo debido a la semántica a prueba de fallas.

El uso de ADT para el manejo de errores proporciona otra ventaja sobre las excepciones: la posibilidad de un error está conectada al tipo en sí y es más difícil pasarla por alto, como cuando se usa Option lugar de valores nulos.