Sensores da fábrica

Os programadores normalmente tentam escrever software perfeito e normalmente falham.

As coisas correm mal, inesperadamente, e precisamos de conseguir lidar com isso.

Alguns criadores de linguagens consideram que a prioridade é detetar um erro o mais depressa possível e depois terminar a execução com uma mensagem informativa que ajude na depuração.

As linguagens de ciência de dados tendem a adotar uma abordagem mais nuançada. Alguns erros são tão graves que é necessária uma terminação imediata, mas muitas vezes é melhor assinalar um problema como algo a tratar mais tarde e continuar a execução.

Vimos no conceito Nada que a Julia disponibiliza vários marcadores de posição para valores problemáticos: missing, NaN e Inf. Se estes são uma abordagem melhor do que a terminação do programa numa determinada situação é uma questão de critério do programador.

Uma nota de nomenclatura antes de entrar nos detalhes: a documentação da Julia trata as palavras "erro" e "exceção" como praticamente intercambiáveis. O conteúdo abaixo pode ser igualmente inconsistente.

Tipos de erro padrão

A esta altura do programa, já deves ter visto muitas mensagens de erro da Julia. Por exemplo:

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

Tentar converter um número de vírgula flutuante num inteiro implica uma perda de precisão, por isso obtemos um InexactError.

O InexactError é um tipo, um dos vários (atualmente 25) que a Julia inclui de série. Todos são subtipos de Exception:

julia> supertype(InexactError)
Exception

throw()

Pode ser útil gerar alguns dos tipos de erro padrão no teu próprio código.

Como todos os tipos concretos, os erros têm construtores. Aceitam uma variedade de argumentos, por isso consulta a documentação do que queres usar.

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

Para usar o erro, envolve o construtor numa função throw():

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

error()

Para uma abordagem rápida e descomplicada, a função error() pode ser prática. Recebe uma string (ou os componentes de uma string) como argumento:

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

Erros personalizados

Criar novos tipos de erro é, em princípio, muito fácil. Basta acrescentar outro subtipo de Exception:

julia> struct MyError <: Exception end

julia> throw(MyError)
ERROR: MyError

Asserções

A ideia básica de uma asserção é "esta afirmação deve ser verdadeira, por isso reclama em voz alta se for falsa". O valor disto está sobretudo na depuração, já que o código de produção nunca deve falhar uma asserção.

Vimos no conceito Tipos que podemos adicionar asserções de tipo, por exemplo para verificar o tipo devolvido por uma função.

julia> 42::Number
42

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

De forma mais geral, a macro @assert permite-nos testar qualquer expressão que seja avaliada como um valor Boolean:

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

try...catch

Alguns erros são necessariamente fatais, mas muitas vezes esperamos que o programa recupere de forma graciosa.

Por predefinição, um erro termina imediatamente a função atual, e o erro (com qualquer mensagem informativa) é passado à função que a chamou.

Isto continua a subir pela pilha de chamadas, até o código de topo terminar com uma mensagem de erro.

Em qualquer fase, o erro pode ser intercetado por um bloco try...catch que tenta tratá-lo.

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

No exemplo acima, log(n) precisa que n seja um valor real positivo ou um valor complexo qualquer. O try ... catch captura os problemas com valores reais negativos e devolve a resposta complexa correta, iπ em notação matemática.

Se forneceres, por exemplo, um argumento do tipo string, não há forma de recuperar a não ser pedir ao utilizador para o corrigir.

Como último recurso genérico, acrescentámos rethrow() para tudo o que não seja um DomainError nem um MethodError.

Nota: Às vezes, um try...catch é o que precisas, mas evita usá-lo em excesso. Se puderes usar um bloco if...else em vez disso, será muito mais eficiente do que capturar exceções.

Registos

Repara que a função error(), discutida acima, não deve ser confundida com a macro @error.

A função gera uma exceção, que vai subir a pilha de chamadas, a menos que seja capturada.

A macro @error, tal como as suas equivalentes @debug, @info e @warn, faz parte do módulo Logging e destina-se a gerar mensagens informativas sem alterar o fluxo do programa.

Por predefinição, a saída vai para o terminal (com cores consoante a gravidade), embora numa aplicação real haja muitas outras possibilidades.

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

Vê também o exemplo anterior, em try...catch.