Sensores de fábrica

Por lo general, los programadores intentan escribir software perfecto, y por lo general fracasan.

Las cosas salen mal, de manera inesperada, y necesitamos poder hacerles frente.

Algunos diseñadores de lenguajes creen que la prioridad es detectar un error lo antes posible y, después, terminar la ejecución con un mensaje informativo que ayude a depurar.

Los lenguajes de ciencia de datos tienden a adoptar un enfoque más matizado. Algunos errores son tan graves que es necesario terminar de inmediato, pero a menudo es mejor señalar un problema como algo que hay que resolver más adelante y continuar la ejecución.

Vimos en el concepto Nada que Julia ofrece varios marcadores de posición para valores problemáticos: missing, NaN e Inf. Que estos sean mejor opción que terminar el programa en una situación concreta es algo que queda al criterio de quien programa.

Una cuestión de nomenclatura antes de entrar en detalles: la documentación de Julia considera que las palabras «error» y «excepción» son en gran medida intercambiables. El contenido que sigue puede ser igualmente incoherente.

Tipos de error estándar

En este punto del temario, seguro que ya has visto muchos mensajes de error de Julia. Por ejemplo:

julia> Int(3.14)
ERROR: InexactError: Int64(3.14)

Intentar convertir un número decimal en un entero implica una pérdida de precisión, así que obtenemos un InexactError.

InexactError es un tipo, uno de los varios (actualmente 25) que Julia incluye de serie. Todos son subtipos de Exception:

julia> supertype(InexactError)
Exception

throw()

Puede que algunos de los tipos de error estándar te resulten útiles para generarlos en tu propio código.

Como todos los tipos concretos, los errores tienen constructores. Aceptan una variedad de argumentos, así que consulta la documentación del que quieras usar.

julia> DomainError(42, "out of range")
DomainError(42, "out of range")

Para usar el error, envuelve el constructor en una función throw():

julia> throw(DomainError(42, "out of range"))
ERROR: DomainError with 42:
out of range

error()

Para un enfoque rápido y poco cuidadoso, la función error() puede resultar cómoda. Toma como argumento un string (o los componentes de un string):

julia> happy = false;
julia> happy || error("😞 something went wrong")
ERROR: 😞 something went wrong

Errores personalizados

Crear nuevos tipos de error es, en principio, muy fácil. Basta con añadir otro subtipo de Exception:

julia> struct MyError <: Exception end

julia> throw(MyError)
ERROR: MyError

Aserciones

La idea básica de una aserción es «esta afirmación debería ser cierta, así que protesta bien alto si resulta falsa». Su valor radica sobre todo durante la depuración, ya que el código en producción nunca debería fallar una aserción.

Vimos en el concepto Tipos que podemos añadir aserciones de tipo, por ejemplo para comprobar el tipo devuelto por una función.

julia> 42::Number
42

julia> "two"::Number
ERROR: TypeError: in typeassert, expected Number, got a value of type String

De forma más general, la macro @assert nos permite comprobar cualquier expresión que se evalúe a un valor booleano:

julia> n = 22;
julia> @assert isodd(n) "n must be odd"
ERROR: AssertionError: n must be odd

try...catch

Algunos errores son necesariamente fatales, pero a menudo esperamos que el programa se recupere con elegancia.

De forma predeterminada, un error termina de inmediato la función actual, y el error (con cualquier mensaje informativo) se pasa a la función que hizo la llamada.

Esto continúa hacia arriba por la pila de llamadas, hasta que el código de nivel superior termina con un mensaje de error.

En cualquier punto, el error se puede interceptar con un bloque try...catch que intente gestionarlo.

julia> n = -1;
julia> try
           log_n = log(n)
       catch problem
           if problem isa DomainError # number out of range
               # See next section for more on @warn and @info
               @warn "you may have supplied a negative real number: $n"
               @info "trying with complex argument"
               log_n = log(Complex(n))  # fallback calculation

           elseif problem isa MethodError # no idea what n is
               @error "please supply a valid argument"
 
           else
              rethrow() # the error could be anything else
           end
      end
┌ Warning: you may have supplied a negative real number: -1
└ @ Main REPL[3]:5
[ Info: trying with complex argument
0.0 + 3.141592653589793im  # success

En el ejemplo anterior, log(n) necesita que n sea un valor real positivo, o cualquier valor complejo. El try ... catch atrapa los problemas con valores reales negativos y devuelve la respuesta compleja correcta, iπ, en notación matemática.

Si proporcionas, por ejemplo, un argumento de tipo string, no hay recuperación posible salvo pedirle al usuario que lo corrija.

Como último recurso general, añadimos rethrow() para cualquier cosa que no sea ni DomainError ni MethodError.

Nota: A veces un try...catch es justo lo que necesitas, pero por favor evita usarlo en exceso. Si en su lugar puedes usar un bloque if...else, tendrá un rendimiento mucho mejor que capturar excepciones.

Registro

Ten en cuenta que la función error(), comentada antes, no debe confundirse con la macro @error.

La función genera una excepción, que se pasará hacia arriba por la pila de llamadas a menos que se capture.

La macro @error, junto con sus equivalentes @debug, @info y @warn, forma parte del módulo Logging y está pensada para generar mensajes informativos sin alterar el flujo del programa.

De forma predeterminada, la salida va a la terminal (codificada por colores según la gravedad), aunque en una aplicación real hay muchas otras posibilidades.

julia> @warn "Something looks not quite right"
┌ Warning: Something looks not quite right
└ @ Main REPL[55]:1

julia> @error "Panic!"
┌ Error: Panic!
└ @ Main REPL[56]:1

Consulta también el ejemplo anterior, en try...catch.