Manejo de fallas con Cualquiera -> ¿Dónde está el stacktrace?

Escuché de algunas personas que en Scala tenemos tendencia (al igual que otros lenguajes funcionales) a no romper el flujo de control ... En lugar de hacerlo por convención, devolvemos el error en un EitherLeft.Manejo de fallas con Cualquiera -> ¿Dónde está el stacktrace?

Pero, ¿cómo obtenemos el StrackTrace de esa excepción? Por ahora, devuelvo en la izquierda una clase simple de caso Error con un código, un mensaje y una causa (Error también). Pero si tengo un error, no puedo obtener la stacktrace. Si mi aplicación se vuelve compleja, puede ser difícil encontrar el bloque de código que devolvió ese Error ... La causa raíz es esencial.

Entonces, ¿qué hacemos en la práctica?

si regreso, en lugar de una costumbre Error, el tipo java Exception o Throwable en mi Left? ¿Cuál es la mejor práctica para el manejo de excepciones de Scala sin perder información importante como stacktrace y la causa?

Fuente

2012-09-16 Sebastien Lorber

Solo como una nota, en la próxima Scala 2.10 [también hay Try] (http://blog.richdougherty.com/2012/06/error-handling-with-scalas-try.html) para el manejo de errores –

@ om-nom-nom ¡gracias, esto parece realmente bueno! –

Sugeriría usar Either[java.lang.Throwable, A] (donde Throwable aún le da acceso al seguimiento de la pila), y (en general) hacer que sus tipos de error personalizados se extiendan java.lang.Exception.

Esta es la práctica utilizada por Dispatch 0.9, por ejemplo, donde Either[Throwable, A] se utiliza para representar cálculos que pueden fallar, y los tipos de error personalizados tener este aspecto:

case class StatusCode(code: Int) 
    extends Exception("Unexpected response status: %d".format(code))

Scalaz 7 's Validation.fromTryCatch(a: => T) también devuelve un Validation[Throwable, T] , donde Validation es aproximadamente equivalente a Either.

Fuente

2012-09-16 19:57:46

Argumentaría que, aunque hay ejemplos de excepciones encapsuladas en un Either, esto es una tontería en la práctica. Si tiene algún esquema de codificación de error, uno de los dos tiene sentido; de lo contrario, solo arroje la excepción para que los que están más arriba en la cadena de llamadas puedan manejarla o pasarla. –

@rs_atl: Supongamos que estoy atascado con la posibilidad de algo así como 'NumberFormatException' cuando intento analizar una cadena en un entero, por ejemplo. Tanto lanzar la excepción como usar una clase de error o envoltorio personalizados me parecen más tontos que el simple enfoque 'O bien [Throwable, Int] '. –

@TravisBrown gracias. ¿Es una buena práctica devolver un Left (Throwable) en lugar de Left (Exception)? Como se supone que no debemos atrapar Throwables de todos modos. Puede llevar a un desarrollador a detectar un error de OutOfMemory, por ejemplo, no? –

Manejo de fallas con Cualquiera -> ¿Dónde está el stacktrace?

Respuesta

Cuestiones relacionadas