Chi programma di solito cerca di scrivere software perfetto, e di solito fallisce.
Le cose vanno storte, inaspettatamente, e dobbiamo essere in grado di affrontarlo.
Alcuni progettisti di linguaggi ritengono che la priorità sia individuare un errore il più rapidamente possibile, poi terminare l'esecuzione con un messaggio informativo che aiuti il debug.
I linguaggi per la data science tendono ad adottare un approccio più articolato.
Alcuni errori sono così gravi che la terminazione immediata è necessaria, ma spesso è meglio segnalare un problema come qualcosa da affrontare più tardi, e poi continuare l'esecuzione.
Nel concetto Nullità abbiamo visto che Julia fornisce vari segnaposto per valori problematici: missing, NaN e Inf.
Se questi siano un approccio migliore rispetto alla terminazione del programma in una situazione particolare è una questione di giudizio del programmatore.
Una precisazione sulla nomenclatura prima di entrare nei dettagli: la documentazione di Julia considera le parole «error» e «exception» in gran parte intercambiabili.
Anche il contenuto che segue potrebbe essere altrettanto incoerente.
Tipi di errore standard
A questo punto del percorso, avrai sicuramente visto molti messaggi di errore da Julia.
Per esempio:
julia> Int(3.14)
ERROR: InexactError: Int64(3.14)
Provare a convertire un numero in virgola mobile in un intero comporta una perdita di precisione, quindi otteniamo un InexactError.
InexactError è un tipo, uno dei diversi (attualmente 25) integrati in Julia come standard.
Sono tutti sottotipi di Exception:
julia> supertype(InexactError)
Exception
throw()
Alcuni dei tipi di errore standard potrebbero essere utili da generare nel codice.
Come tutti i tipi concreti, gli errori hanno costruttori.
Accettano una varietà di argomenti, quindi controlla la documentazione per quello che vuoi usare.
julia> DomainError(42, "out of range")
DomainError(42, "out of range")
Per usare l'errore, avvolgi il costruttore in una funzione throw():
julia> throw(DomainError(42, "out of range"))
ERROR: DomainError with 42:
out of range
error()
Per un approccio rapido e senza troppi fronzoli, la funzione error() può essere comoda.
Accetta una stringa (o i componenti di una stringa) come argomento:
julia> happy = false;
julia> happy || error("😞 something went wrong")
ERROR: 😞 something went wrong
Errori personalizzati
Creare nuovi tipi di errore è in linea di principio molto facile.
Basta aggiungere un altro sottotipo di Exception:
julia> struct MyError <: Exception end
julia> throw(MyError)
ERROR: MyError
Asserzioni
L'idea di base di un'asserzione è «questa affermazione dovrebbe essere vera, quindi protesta a gran voce se è falsa».
Il valore di questo sta principalmente durante il debug, dato che il codice di produzione non dovrebbe mai fallire un'asserzione.
Nel concetto Tipi abbiamo visto che possiamo aggiungere asserzioni di tipo, per esempio per controllare il tipo restituito da una funzione.
julia> 42::Number
42
julia> "two"::Number
ERROR: TypeError: in typeassert, expected Number, got a value of type String
Più in generale, la macro @assert ci permette di verificare qualsiasi espressione che produca un valore booleano:
julia> n = 22;
julia> @assert isodd(n) "n must be odd"
ERROR: AssertionError: n must be odd
try...catch
Alcuni errori sono necessariamente fatali, ma spesso ci aspettiamo che il programma si riprenda con grazia.
Per impostazione predefinita, un errore termina immediatamente la funzione corrente, e l'errore (con qualsiasi messaggio informativo) viene passato alla funzione chiamante.
Questo continua su per lo stack di chiamate, finché il codice di livello superiore termina con un messaggio di errore.
In qualsiasi momento, l'errore può essere intercettato con un blocco try...catch che prova a gestirlo.
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
Nell'esempio sopra, log(n) richiede che n sia un valore reale positivo oppure un valore complesso qualsiasi.
Il try ... catch intercetta i problemi con valori reali negativi, restituendo la risposta complessa corretta iπ in notazione matematica.
Se fornisci, per esempio, un argomento di tipo stringa, non c'è modo di recuperare se non chiedere all'utente di correggerlo.
Come ultima rete di sicurezza, abbiamo aggiunto rethrow() per tutto ciò che non è né DomainError né MethodError.
Nota: A volte un try...catch è quello che serve, ma evita di abusarne.
Se al suo posto si può usare un blocco if...else, sarà molto più performante che catturare eccezioni.
Logging
Nota che la funzione error(), discussa sopra, non va confusa con la macro @error.
La funzione genera un'eccezione, che verrà propagata su per lo stack di chiamate a meno che non venga intercettata.
La macro @error, insieme alle sue controparti @debug, @info e @warn, fa parte del modulo Logging ed è pensata per generare messaggi informativi senza alterare il flusso del programma.
L'output va al terminale per impostazione predefinita (con colori che ne indicano la gravità), anche se in un'applicazione reale ci sono molte altre possibilità.
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
Vedi anche l'esempio precedente, sotto try...catch.
Esercizio di apprendimento
