Newsgroup: it.comp.programmare
Titolo: Esiste la "tecnologia degli errori"?

Che voi sappiate, esistono studi, articoli e/o tecnologie su come
diagnosticare e identificare gli errori dei programmi in modo che siano
il più possibile significativi e utili?
Voglio dire, il solito caso del programma che riporta "errore
all'indirizzo 0x4282456: la memoria non poteva essere read" o tanti
antri casi di messaggi di errore corretti ma assolutamente criptici e
insignificanti per un utente medio (e pure per uno non tanto medio), che
alla fine rinuncia completamente a vedere che errore è e chiama
direttamente l'assistenza dicendo che "non funziona"...
Esiste qualcuno da qualche parte che si è occupato di studiare un modo
migliore di diagnosticare e notificare un errore? Io ho cercato qualcosa
su Google ma non ho trovato molto. Qualcuno qui ne sa di più?

Massimo Soricetti ha scritto:

Interesserebbe anche a me conoscere studi su questo argomento.
Ma posso dire che è necessario distinguere tra vari tipi di errori:
1) Errori dell'utente gestiti dall'applicazione. Per esempio, l'utente 
inserisce l'anno 20008 e' il programma gli dice che e' un valore troppo 
grande.
2) Errori del programmatore gestiti da un'altra parte dell'applicazione. 
Per esempio, una routine tenta di allocare memoria, ma l'allocazione 
fallisce, viene sollevata un'eccezione che viene catturata dalla routine 
chiamante, la quale segnala all'utente che l'operazione e' fallita per 
insufficienza di memoria.
3) Errori del programmatore non gestiti dal codice applicativo, ma 
gestiti da una libreria usata dall'applicazione sviluppata da un'altra 
organizzazione (per esempio, la libreria standard del linguaggio). Per 
esempio, se l'applicazione e' sviluppata all'interno di un framework che 
cattura tutte le eccezioni sollevate dal codice applicativo, e il codice 
applicativo solleva un'eccezione per fallimento di allocazione di 
memoria, ma non cattura tale eccezione.
4) Errori del programmatore non gestiti dall'applicazione ne' dalle sue 
librerie, ma gestiti dal sistema operativo. Per esempio, accedere a un 
indirizzo di memoria non riservato al processo, con conseguente 
messaggio "la memoria non poteva essere read".
5) Errori del programmatore non gestiti neanche dal sistema operativo (e 
quindi si tratta di difetti del sistema operativo). Per esempio, blocco 
del sistema a causa di un accesso a un indirizzo di memoria non 
riservato al processo.
Alcuni consigli che posso dare sono i seguenti:
* Associa un codice numerico univoco a ogni messaggio d'errore generato 
dall'applicazione.
* Mostra il codice d'errore in ogni segnalazione all'utente dell'errore, 
in modo che l'utente possa riferirti esattamente quale errore si e' 
verificato. Ovviamente, mostra anche un messaggio descrittivo.
* Scrivi il programma in modo da poter trovare rapidamente il punto in 
cui e' stato emesso un dato messaggio d'errore. Per esempio, se emetti i 
messaggi d'errore esclusivamente chiamando la funzione ShowError(###), 
dove ### e' il codice dell'errore, per trovare l'errore 15 bastera' 
cercare la stringa "ShowError(15)".
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

il più possibile significativi e utili?
Mi sembra un po' eccessivo parlare di "studi" per un tema del genere.
Direi che la cosa più intelligente da fare è avere comunque e sempre
un log degli errori e, per lo stesso errore, due differenti messaggi:
uno da loggare ed indirizzato ai tecnici, l'altro esplicativo ed
indirizzato all'utente. Se l'utente segnala un errore, fornendoti un
codice, tu puoi rintracciare nel tuo log la descrizione "tecnica"
dell'errore ed agire di conseguenza.

 verificato. Ovviamente, mostra anche un messaggio descrittivo.
Eh no... questo è _esattamente_ il tipo di trafila che volevo evitare.
L'idea di fondo è di scrivere il software in modo da rendere autonomo
l'utente (per quello che si può) nella diagnosi e risoluzione degli
errori, minimizzando la necessità di chiamate al supporto tecnico con
guadagno e felicità di entrambe le parti.
Non tutti gli errori possono essere risolti dall'utente e questo è
pacifico, ma fare in modo che il più possibile lo siano è l'obiettivo
che mi prefiggo.
Per questo credo che sia necessario implementare nel programma stesso
una specie di diagnostico integrato che tenga traccia delle ultime
azioni dell'utente e degli eventi sulla macchina, e cerchi di trarre un
senso da essi in modo da offrire all'utente non solo un messaggio di
errore, ma anche la causa più probabile (preferibilmente LA causa
esatta) e una procedura di risoluzione. E se è necessario chiamare il
tecnico, dica almeno PERCHE' non si può fare altro che chiamarlo, invece
che "non funziona" o "errore 3644733"...

 che "non funziona" o "errore 3644733"...
Quello che gli utenti raccontano di aver fatto non e' molto affidabile, 
sia perche' gli stessi programmatori spesso non sanno esattamente che 
cosa hanno fatto quando riproducono un errore, sia perche' gli utenti 
spesso si esprimono in modo poco rigoroso.
Piuttosto e' meglio raccogliere in modo automatico quante piu' 
informazioni possibile (tramite logging, core dump, o stack trace) e 
spedirle al programmatore.


 all'indirizzo 0x4282456: la memoria non poteva essere read" o tanti
Se usi linguaggi managed come Java o Python al posto di questi messaggi 
criptici ottieni uno stack trace che indica tutte le funzioni chiamate 
prima di arrivare all'errore.
A meno che l'errore non sia nell'interprete/virtual machine.
-- 
overhea...@see-the-signature.invalid
Replace "see-the-signature.invalid" with "
gmail.com
"