Sensores de fábrica

Programadores em geral tentam escrever software perfeito, e em geral falham.

As coisas dão errado, de forma inesperada, e precisamos conseguir lidar com isso.

Alguns criadores de linguagens acreditam que a prioridade é detectar um erro o mais rápido possível e então encerrar a execução com uma mensagem informativa para ajudar na depuração.

Linguagens de ciência de dados tendem a adotar uma abordagem mais nuançada. Alguns erros são tão graves que o encerramento imediato é necessário, mas muitas vezes é melhor sinalizar um problema como algo a ser tratado mais tarde e então continuar a execução.

Vimos no Conceito Nada que o Julia oferece vários marcadores para valores problemáticos: missing, NaN e Inf. Se esses marcadores são uma abordagem melhor do que encerrar o programa em uma situação específica é uma questão de julgamento do programador.

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

Tipos de erro padrão

Neste ponto do programa de estudos, você já deve ter visto muitas mensagens de erro do Julia. Por exemplo:

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

Tentar converter um número de ponto flutuante em um inteiro envolve uma perda de precisão, então obtemos um InexactError.

InexactError é um tipo, um de vários (atualmente 25) embutidos no Julia como padrão. Todos são subtipos de Exception:

julia> supertype(InexactError)
Exception

throw()

Talvez seja útil gerar alguns dos tipos de erro padrão no seu próprio código.

Como todos os tipos concretos, os erros têm construtores. Eles aceitam uma variedade de argumentos, então consulte a documentação para o que você quer usar.

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

Para usar o erro, envolva o construtor em uma função throw():

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

error()

Para uma abordagem rápida e improvisada, a função error() pode ser conveniente. Ela 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 adicionar 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 deveria ser verdadeira, então reclame alto se ela for falsa". Isso tem valor principalmente durante a depuração, já que código em produção nunca deveria falhar em uma asserção.

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

julia> 42::Number
42

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

De modo mais geral, a macro @assert nos permite testar qualquer expressão que avalie para um 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 se recupere de forma elegante.

Por padrão, um erro encerra imediatamente a função atual, e o erro (com qualquer mensagem informativa) é passado para a função que fez a chamada.

Isso continua subindo pela pilha de chamadas, até que o código de nível superior termine com uma mensagem de erro.

Em qualquer etapa, o erro pode ser interceptado com 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 qualquer valor complexo. O try ... catch captura problemas com valores reais negativos, retornando a resposta complexa correta iπ em notação matemática.

Se você fornecer, por exemplo, um argumento do tipo string, não há recuperação possível a não ser pedir ao usuário que o corrija.

Como uma captura final abrangente, adicionamos rethrow() para qualquer coisa que não seja DomainError nem MethodError.

Observação: Às vezes um try...catch é o que você precisa, mas evite usá-lo em excesso. Se um bloco if...else puder ser usado em vez disso, ele terá um desempenho muito melhor do que capturar exceções.

Registro de logs

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

A função gera uma exceção, que será passada para cima na pilha de chamadas a menos que seja capturada.

A macro @error, junto com suas equivalentes @debug, @info e @warn, faz parte do módulo Logging e serve para gerar mensagens informativas sem alterar o fluxo do programa.

A saída vai para o terminal por padrão (com cores conforme a gravidade), embora em uma aplicação real existam 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

Veja também o exemplo anterior, em try...catch.