Quali sono i problemi dello sviluppatore con i messaggi di errore utili? [chiuso]

Anche se ci sono molti esempi di messaggi di errore errati che semplicemente non dovrebbero essere, devi tenere a mente che non è sempre possibile fornire le informazioni che vorresti vedere.

Esiste anche la preoccupazione di esporre troppe informazioni, che potrebbero portare gli sviluppatori a commettere errori sul lato della cautela. (Ti prometto che il gioco di parole non era destinato, ma non lo rimuoverò ora che l'ho notato.)

A volte, c'è anche il fatto che un messaggio di errore complesso è inutile per l'utente finale. Siding con sovraccarico di informazioni non è necessariamente un buon approccio per i messaggi di errore. (Potrebbe essere meglio salvare per la registrazione.)

Gli sviluppatori non sono le persone giuste per scrivere messaggi di errore.

Vedono l'applicazione dall'angolo sbagliato. Sono estremamente consapevoli di cosa è andato storto all'interno del codice, ma spesso non si avvicinano al software dal punto di vista del tentativo di realizzare qualcosa. Di conseguenza, le informazioni importanti per lo sviluppatore non sono necessariamente informazioni importanti per l'utente.

La vista di beneficenza:

• Lo sviluppatore ha lavorato a stretto contatto con il codice e ha faticato a comprendere qualcuno che non aveva la capacità di comprenderlo. Di conseguenza loro pensano che i messaggi di errore siano a posto, semplicemente non hanno un buon quadro di riferimento con il quale giudicarli.

• I messaggi di errore intelligenti sono effettivamente difficili da fare. Non solo scrivendoli ma devi risolvere tutto ciò che potrebbe andare storto, valutare la verosimiglianza e fornire informazioni utili (che quasi sicuramente variano in base al contesto) alla persona che legge il messaggio per consentire loro di risolverlo.

• Per la maggior parte delle applicazioni è difficile dare il buon tempo per fare questo genere di cose e il prossimo sviluppatore vorrebbe davvero perché gli errori non si verificano spesso. Inoltre, se avessi quel tempo extra non dovresti spenderlo fermando gli errori invece di segnalarli?

La vista non banale:

• I messaggi di errore e la gestione degli errori sono noiosi, ci sono cose molto più interessanti su cui lavorare e il mio capo è sulla mia schiena per la prossima cosa. Capisco questo codice, starò bene, il prossimo lo risolverà e alla fine sarò fuori di qui quindi non è un mio problema.

La realtà è probabilmente da qualche parte nel mezzo, anche se la mia esperienza in realtà mi dice che è molto più la prima che la più recente - in pratica è piuttosto difficile e richiede un discreto sforzo per affrontare qualcosa che probabilmente non accadrà.

Sfortunatamente, più messaggi di errore utili costano tempo allo sviluppatore, che equivale a denaro della società. I prodotti sono abbastanza costosi da costruire così com'è. Sì, sarebbe fantastico avere più utili messaggi di errore e sono d'accordo che dovrebbero esserci altri più utili. Tuttavia, è solo un dato di fatto che quando sei sotto una scadenza, e il denaro è in gioco, devi tagliare qualcosa. "Messaggi di errore più carini", come i manager potrebbero vederlo, sarà probabilmente la prima cosa da fare.

Sono d'accordo che i messaggi di errore dovrebbero essere il più specifici possibile.

Un motivo per i messaggi di errore generici è probabilmente l'uso di codici di errore. Quando si utilizzano le eccezioni, si è liberi di passare tutto ciò che è necessario nel messaggio di errore. Usando i codici di ritorno non c'è spazio per codificare un nome di colonna. Forse l'errore è gestito da una funzione generica che non conosce il contesto e traduce semplicemente il codice di errore in una stringa.

• A volte troppe informazioni possono essere un rischio per la sicurezza; non sai chi sta leggendo il messaggio di errore
• A volte l'operazione che ha generato l'eccezione è così complessa che è impossibile ottenere un messaggio significativo senza effetti negativi sulla velocità / complessità del codice

Come avviso generale, dovresti considerare che qualsiasi errore o situazione eccezionale è - esattamente questo: eccezionale. Taglia trasversalmente la procedura pianificata e progettata. È incompatibile con il modo in cui le cose hanno programmato di funzionare. Se così non fosse, non ci sarebbe alcun bisogno di uscire con un errore.

Noi programmatori siamo addestrati a prenderci cura dell'autoprotezione di questa procedura pianificata. Pertanto, includiamo regolarmente alcuni controlli di integrità per verificare le nostre ipotesi. Quando questi controlli di integrità falliscono, sappiamo solo che il piano in qualche modo ha fallito ...

La tua richiesta - potrebbe sembrare del buon senso dal punto di vista dell'utente - è impossibile da soddisfare, se si considera la realtà di come funziona un tale sistema. Chiedete una dichiarazione ordinata con le informazioni ben organizzate e adatte aggiunte. Inoltre, chiedi addirittura che questa presentazione avvenga in un modo che si adatta al progetto generale di applicazione / gestione. Ovviamente questa informazione esiste da qualche parte nel sistema. Ovviamente esiste anche lì in maniera ordinata e ben organizzata (lasciamo sperare così). MA nel momento in cui si verifica l'errore, nessuno ha mai pianificato di rendere disponibili queste informazioni. Un errore è sempre una perdita parziale di controllo. Questa perdita di controllo può avvenire su vari livelli. Potrebbe essere il comportamento del sistema in fase di esecuzione in modo diverso rispetto a quanto pianificato. Ma potrebbe anche essere che l'effettiva implementazione si sia rivelata molto più difficile e diversa nei dettagli poi pianificati, e non vi era alcuna disposizione in grado di gestire questa situazione soddisfacente. Anche questa è una perdita parziale di controllo.

Per mettere in relazione questo con l'esempio concreto che hai dato: Se, al punto dell'errore, si conoscessero il nome e il tipo della colonna della tabella e in aggiunta la lunghezza dello spazio richiesto, non ci sarebbe qualsiasi motivo per sollevare un errore, non è vero? Potremmo semplicemente sistemare la situazione e procedere come previsto. Il fatto stesso che siamo costretti a generare un errore ci mostra che le cose sono andate fuori strada. Il fatto stesso che queste informazioni non siano a portata di mano è l'eccezione .

Quello che sto scrivendo qui può sembrare ovvio e semplice buon senso. Ma in realtà è estremamente difficile da capire. Cerchiamo costantemente di capirlo applicando categorie morali - come ci deve essere un colpevole, ci deve essere una persona pigra cattiva che non si cura per l'utente povero, ci deve essere un avido uomini d'affari che fatto un modo per il calcolo a buon mercato. Tutto questo è completamente oltre al punto

La possibilità di perdere il controllo deriva dal fatto stesso che stiamo facendo le cose in modo pianificato e ordinato .

Lavoro come tecnico di supporto per una ditta di software e spesso vediamo messaggi di errore che sono nuovi per noi. Spesso quando li rimando al nostro team di sviluppo, devono cercare il messaggio nell'origine dell'applicazione.

Mi sembra che anche se non fosse presentato agli utenti, sarebbe sicuro per noi un sacco di tempo se il team di sviluppo aggiungesse una nota a un documento di indice di errore o un database ogni volta che ne aggiungevano uno nuovo renderebbe molto più rapido per noi trovare la causa dei problemi dei clienti e far loro risparmiare tempo ...

Il problema che stai vedendo è in realtà uno degli effetti collaterali di incapsulamento e occultamento delle informazioni.

I sistemi moderni sono estremamente complicati. Ci sono poche possibilità che lo sviluppatore medio sia in grado di mantenere, nella sua testa, un modello mentale dell'intero sistema dall'interfaccia utente al binario grezzo mentre sta codificando ogni particolare compito.

Quindi, mentre uno sviluppatore è seduto e codifica, ad esempio, il bit che ripristina un file di database, il suo modello mentale è completamente occupato dai bit che circondano l'atto di ripristinare un file di database. Ha bisogno di (e sto indovinando, non ho scritto questo codice) leggere un file, controllare le proprietà, leggere le versioni, fare il backup dei dati esistenti, scegliere una strategia di unione / sovrascrittura, ecc. Molto probabilmente, se c'è anche un passaggio considerazione per l'interfaccia utente, è nella stringa di errore che scrive in un gestore di eccezioni. Qualcosa come:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

In questo esempio, le informazioni utili che stai chiedendo in termini di processi che potrebbero utilizzare il file, o anche altri thread nel DB, sono completamente fuori portata (programmaticamente). Possono esserci centinaia di classi che gestiscono file DB; importando in tali classi informazioni su ogni altro processo che utilizza i file, o funzionalità per accedere al file system e guardare gli altri processi in esecuzione (supponendo che quei processi siano anche su QUESTA macchina) porterebbe a ciò che è noto come astrazione che perde ; c'è un costo diretto in produttività.

Ecco come possono persistere questi tipi di errori nei giorni moderni. Ovviamente, tutti potrebbero essere riparati; ma in molti casi, ci sono molti più overhead coinvolti di quanto si possa pensare (in questo caso, ad esempio, potrebbe essere necessario che questa funzione attraversi l'enumerazione delle connessioni di rete e condivisioni per vedere se una macchina remota sta usando questo file di database per alcuni motivo) e il costo è tutt'altro che banale.

Il mio preferito era (alla fine degli anni '70) il compilatore Univac Fortran IV, durante la lettura di non-cifre, fedelmente annunciato

The interpretation of meaningless data was attempted

Credo che la maggior parte dei messaggi di errore siano in realtà istruzioni di code / printf glorificate di programmazione (self) orientate al programmatore.

Scrivere messaggi di errore orientati all'utente significa sapere chi è il tuo utente e anticipare ciò che vorranno sapere. Mentre sta scrivendo il codice, uno sviluppatore è più propenso a scrivere un messaggio di errore utile a se stesso, sia per il debugging del codice che sta scrivendo in quel momento, sia per il caso noto o predominante.

Passare dalla scrittura del codice alla progettazione di una parte testuale dell'interfaccia utente (o esperienza utente) è un interruttore di contesto. Nelle applicazioni di grandi dimensioni, come le applicazioni multilingue che potrebbero significare che viene trasferito a un'altra persona o team (UI, traduzione) piuttosto che interamente gestito dallo sviluppatore, quindi, a meno che lo sviluppatore non spieghi attentamente il contesto del messaggio, i dettagli importanti possono essere facilmente perso.

Ovviamente, il controllo e la verifica della gestione degli errori è spesso considerato una priorità bassa, a patto di errori e amp; le eccezioni sono gestite (cioè catturate), non viene data molta enfasi ad esso. È un luogo mentalmente insignificante della base di codice per sviluppatori o QA da valutare, poiché le condizioni di errore spesso hanno una connotazione negativa (cioè un errore o un fallimento) associato a esse.

Penso che il motivo sia che la segnalazione / gestione degli errori viene sempre eseguita come dopo il pensiero . Anche quando non sono interamente pensati, sono per lo più cittadini di seconda classe nel design generale.

Il software moderno di solito consiste in più livelli. Quando la tua logica di segnalazione degli errori viene decisa in fretta senza troppo pensare, è spesso difficile raccogliere tutte le informazioni richieste per presentare utili messaggi di errore.

Ad esempio, l'errore è catturato nel back-end, ma ha bisogno di alcune informazioni dai livelli superiori per comporre un messaggio di errore completo. I messaggi di errore più buoni richiedono informazioni da quasi tutti i livelli tutti (per darci una visione completa di ciò che è accaduto nel sistema). Il messaggio di errore ideale sarebbe "OK, prima abbiamo ricevuto una stringa, poi è passato attraverso il parser che ha dato qualcosa di divertente, potreste voler guardare lì. In ogni caso, la cosa è passata più in basso ..."

Facendolo spesso sarebbe necessario un accoppiamento non necessario se il meccanismo di segnalazione degli errori non fosse cittadino di prima classe durante la fase di progettazione. Immagino che molte persone trovino troppo lavoro da fare per qualcosa che non sembra impressionante (a chi piace dire "Vedi? Il mio programma si è bloccato e il messaggio di errore è utile!").