Perché molti messaggi di eccezione non contengono dettagli utili?

Sembra che ci sia un certo accordo sul fatto che i messaggi di eccezione debbano contenere dettagli utili .

Perché molte eccezioni comuni dai componenti di sistema non contengono dettagli utili?

Alcuni esempi:

• .NET Listaccesso indice ArgumentOutOfRangeExceptionnon non mi dica il valore di indice che è stato provato e non era valido, né mi dice il range consentito.
• Fondamentalmente tutti i messaggi di eccezione dalla libreria standard MS ++ C ++ sono assolutamente inutili (nella stessa vena di cui sopra).
• Eccezioni Oracle in .NET, che ti dicono (parafrasato) "TABELLA O VISUALIZZA non trovata", ma non quale .

Quindi, a me sembra che per la maggior parte dei messaggi di eccezione parte non contengono informazioni sufficienti per essere utile. Le mie aspettative sono fuori linea? Sto usando le eccezioni sbagliate che ho notato anche questo? O forse la mia impressione è sbagliata: la maggioranza di eccezioni non effettivamente fornire dettagli utili?

Le eccezioni non contengono dettagli utili perché il concetto di eccezioni non è ancora maturato abbastanza nella disciplina dell'ingegneria del software, quindi molti programmatori non le comprendono completamente e quindi non le trattano correttamente.

Sì, IndexOutOfRangeExceptiondovrebbe contenere l'indice preciso che non rientrava nell'intervallo, nonché l'intervallo valido al momento del lancio ed è spregevole per conto dei creatori del runtime .NET che non lo è. Sì, l' table or view not foundeccezione di Oracle dovrebbe contenere il nome della tabella o della vista che non è stata trovata e, di nuovo, il fatto che non sia spregevole da parte di chiunque ne sia responsabile.

In gran parte, la confusione deriva dall'idea originale sbagliata secondo cui le eccezioni dovrebbero contenere messaggi leggibili dall'uomo, che a loro volta derivano dalla mancanza di comprensione di quali siano le eccezioni, quindi è un circolo vizioso.

Poiché le persone pensano che l'eccezione debba contenere un messaggio leggibile dall'uomo, credono che qualunque informazione sia trasportata dall'eccezione dovrebbe anche essere formattata nel messaggio leggibile dall'uomo, e quindi si annoiano a scrivere tutto il messaggio leggibile dall'uomo- codice di costruzione, o temono che ciò potrebbe rivelare una quantità sconsigliata di informazioni a qualunque occhio indiscreto possa vedere il messaggio. (I problemi di sicurezza menzionati da altre risposte.)

Ma la verità è che non dovrebbero preoccuparsene perché l'eccezione non dovrebbe contenere un messaggio leggibile dall'uomo. Le eccezioni sono cose che solo i programmatori dovrebbero mai vedere e / o affrontare. Se c'è mai la necessità di presentare informazioni di errore a un utente, ciò deve essere fatto a un livello molto alto, in modo sofisticato e nella lingua dell'utente, che, statisticamente parlando, è improbabile che sia l'inglese.

Quindi, per noi programmatori, il "messaggio" dell'eccezione è il nome della classe dell'eccezione e qualsiasi altra informazione pertinente all'eccezione deve essere copiata nelle variabili membro (finale / sola lettura) dell'oggetto eccezione. Preferibilmente, ogni singolo piccolo concepibile di esso. In questo modo, nessun messaggio deve (o dovrebbe) essere generato, e quindi nessun occhio indiscreto può vederlo.

Per rispondere alla preoccupazione espressa da Thomas Owens in un commento qui sotto:

Sì, certo, a un certo livello, si verrà creare un messaggio di registro per quanto riguarda l'eccezione. Ma vedi già il problema con quello che stai dicendo: da un lato, un messaggio di registro delle eccezioni senza una traccia dello stack è inutile, ma d'altra parte, non vuoi che l'utente veda l'intera traccia dello stack delle eccezioni. Ancora una volta, il nostro problema qui è che la nostra prospettiva è distorta dalle pratiche tradizionali. I file di registro sono stati tradizionalmente in testo semplice, il che potrebbe essere andato bene mentre la nostra disciplina era agli inizi, ma forse non più: se esiste un problema di sicurezza, il file di registro deve essere binario e / o crittografato.

Che si tratti di testo binario o semplice, il file di registro deve essere considerato come un flusso in cui l'applicazione serializza le informazioni di debug. Tale flusso sarebbe solo per gli occhi dei programmatori e il compito di generare informazioni di debug per un'eccezione dovrebbe essere semplice quanto serializzare l'eccezione nel flusso di log di debug. In questo modo, guardando il registro si arriva a vedere il nome della classe di eccezione (che, come ho già detto, è per tutti gli scopi pratici "il messaggio"), ciascuna delle variabili del membro di eccezione che descrivono tutto ciò che è pertinente- e-pratico-da-includere-in-un-registro e l'intera traccia dello stack. Si noti come la formattazione di un messaggio di eccezione leggibile dall'uomo manchi in modo evidente da questo processo.

PS

Alcuni altri miei pensieri su questo argomento possono essere trovati in questa risposta: Come scrivere un buon messaggio di eccezione

PPS

Sembra che molte persone siano state tratteggiate dal mio suggerimento sui file di registro binari, quindi ho modificato ancora una volta la risposta per rendere ancora più chiaro che ciò che sto suggerendo qui non è che il file di registro dovrebbe essere binario, ma che il file di registro può essere binario, se necessario.

Perché molte eccezioni comuni dai componenti di sistema non contengono dettagli utili?

Nella mia esperienza, ci sono una serie di ragioni per cui le eccezioni non contengono informazioni utili. Mi aspetto che questo tipo di ragioni si applichi anche ai componenti di sistema, ma non lo so per certo.

• Le persone incentrate sulla sicurezza vedono le eccezioni come una fonte di perdita di informazioni (ad esempio ). Poiché il comportamento predefinito delle eccezioni è di mostrare tali informazioni all'utente, i programmatori a volte sbagliano sul lato della cautela.
• In C ++, ho sentito argomenti contro l'allocazione della memoria nei blocchi catch (in cui si trova almeno un po 'del contesto per creare buoni messaggi). Tale allocazione è difficile da gestire e, peggio, può causare un'eccezione di memoria insufficiente lì - spesso si blocca l'app o si perde la memoria. È difficile formattare bene le eccezioni senza allocare memoria e questa pratica potrebbe essere migrata tra le lingue come fanno i programmatori.
• Non lo sanno. Voglio dire, ci sono scenari in cui il codice non ha idea di cosa sia andato storto. Se il codice non lo sa, non può dirtelo.
• Ho lavorato in luoghi in cui i problemi di localizzazione impedivano di inserire nel sistema solo stringhe in inglese, anche per eccezioni che sarebbero state lette solo dal personale di supporto di lingua inglese.
• In alcuni posti, ho visto eccezioni usate più come asserzioni. Sono lì per fornire un messaggio chiaro e forte durante lo sviluppo che qualcosa non è stato fatto o che un cambiamento è stato fatto in un posto, ma non in un altro. Questi sono spesso abbastanza unici che un buon messaggio sarebbe uno sforzo duplicato o semplicemente confuso.
• Le persone sono pigre, i programmatori più della maggior parte. Trascorriamo molto meno tempo sul percorso eccezionale rispetto al percorso felice, e questo è un effetto collaterale.

Le mie aspettative sono fuori linea? Sto usando le eccezioni sbagliate che ho notato anche questo?

Tipo? Voglio dire, le eccezioni dovrebbero avere dei bei messaggi, ma sono anche delle eccezioni . Dovresti dedicare il tuo tempo a progettare codice per evitare condizioni eccezionali o scrivere codice per gestire condizioni eccezionali (ignorando il messaggio), non utilizzandole come una sorta di meccanismo di feedback interattivo durante la codifica. È inevitabile usarli per scopi di debug, ma nella maggior parte delle situazioni dovrebbe essere ridotto al minimo. Il fatto che tu noti questo problema mi fa preoccupare che non stai facendo un buon lavoro per prevenirli.

Non ho un eccesso di esperienza C # o C ++ in particolare, ma posso dirti questo: le eccezioni scritte dallo sviluppatore 9 volte su 10 sono più utili di qualsiasi eccezione generica che tu abbia mai trovato, punto.

Idealmente sì, un'eccezione generica ti indicherà esattamente perché si è verificato l'errore e sarai in grado di risolverlo facilmente - ma realisticamente, in applicazioni di grandi dimensioni con più classi che possono generare una vasta gamma di diversi tipi di eccezioni, oppure stesso tipo di eccezioni, è sempre più utile scrivere il proprio output per la restituzione dell'errore piuttosto che fare affidamento sul messaggio predefinito.

Ecco come dovrebbe essere, perché come molte persone hanno sottolineato, alcune applicazioni non vogliono lanciare un messaggio di errore che non vogliono che l'utente veda, per motivi di sicurezza o per evitare di confonderle.

Invece, dovresti anticipare nella tua progettazione quali tipi di errori potrebbero essere generati nella tua applicazione (e ci saranno sempre errori) e scrivere messaggi che catturano gli errori che ti aiutano a identificare il problema.

Questo non ti aiuterà sempre - perché non puoi sempre prevedere quale messaggio di errore sarà utile - ma è il primo passo per capire meglio la tua applicazione nel lungo periodo.

La domanda è in particolare chiedersi perché così tante eccezioni generate da "componenti di sistema" (ovvero classi di librerie standard) non contengano dettagli utili.

Sfortunatamente, la maggior parte degli sviluppatori non scrive i componenti principali nelle librerie standard, né i documenti di progettazione dettagliati o altre motivazioni di progettazione sono necessariamente resi pubblici. In altre parole, potremmo non saperlo mai per certo.

Tuttavia, ci sono due punti chiave da tenere a mente sul perché informazioni dettagliate sull'eccezione potrebbero non essere desiderabili o importanti:

1. Un'eccezione può essere utilizzata chiamando il codice in qualsiasi modo: una libreria standard non può porre vincoli sul modo in cui viene utilizzata l'eccezione. In particolare, può essere visualizzato per l'utente. Considera un indice di array fuori limite: questo può fornire informazioni utili a un utente malintenzionato. Il progettista del linguaggio non ha idea di come un'applicazione utilizzerà l'eccezione generata o anche di che tipo di applicazione è (ad esempio app Web o desktop), quindi tralasciare le informazioni potrebbe essere più sicuro dal punto di vista della sicurezza.

2. Le eccezioni non devono essere visualizzate per l'utente. Invece, visualizza un messaggio di errore amichevole e registra l'eccezione in una posizione a cui un attaccante non ha accesso (se applicabile). Una volta identificato l'errore, uno sviluppatore dovrebbe eseguire il debug attraverso il codice, ispezionando i frame dello stack e i percorsi logici. A questo punto, lo sviluppatore ha più informazioni di quante un'eccezione possa mai sperare di avere.

Prima di tutto, lasciami scoppiare una bolla dicendo anche se il messaggio diag è caricato con informazioni che ti portano alla riga di codice e al comando secondario esatti in 4 secondi, è probabile che gli utenti non lo scriveranno mai o non lo diranno alla gente dell'assistenza e ti verrà detto "Beh, ha detto qualcosa su una violazione ... Non so che sembrava complicato!"

Sto scrivendo software e supportando i risultati di altri software da oltre 30 anni ormai, e personalmente, la qualità attuale di un messaggio di eccezione non ha praticamente nulla a che fare con la sicurezza, indipendentemente da come i risultati finali sono stati adattati al loro modello di l'universo, molto più a che fare con il fatto che così tanti nel nostro settore erano originariamente autodidatti e non includevano mai lezioni di comunicazione. Forse se FORZIAMO tutti i nuovi programmatori in una posizione di manutenzione per un paio d'anni in cui dovevano occuparsi di capire cosa era andato storto, avrebbero capito l'importanza di almeno una qualche forma di precisione.

Di recente, in una domanda in fase di ricostruzione, è stata presa la decisione che i codici di ritorno sarebbero rientrati in uno dei tre gruppi:

• 0 a 9 sarebbe successo attraverso successo con informazioni aggiuntive.
• Da 10 a 99 sarebbero errori non irreversibili (recuperabili) e
• 101 a 255 sarebbero errori fatali.

(100 è stato per qualche motivo escluso)

In ogni particolare flusso di lavoro, il nostro pensiero è stato riutilizzato o il codice generico avrebbe utilizzato i rendimenti generici (> 199) per errori fatali, lasciandoci con 100 errori fatali possibili per un flusso di lavoro. Con una leggera differenziazione dei dati nel messaggio, errori come il file non trovato potrebbero tutti utilizzare lo stesso codice e differenziarsi con i messaggi.

Quando il codice tornasse dagli appaltatori, non crederesti alla nostra sorpresa quando praticamente OGNI SINGOLO ERRORE FATALE era il codice di ritorno 101.

Tutto ciò considerato, penso che la risposta alla tua domanda sia che i messaggi sono così insignificanti perché, quando originariamente creati, dovevano essere segnaposto a cui nessuno è tornato. Alla fine la gente ha capito come risolvere i problemi non a causa dei messaggi ma li DISPITE.

Da quel momento, le persone autodidatta non hanno mai avuto un buon esempio di cosa dovrebbe contenere un'eccezione. Aggiungete a ciò che più utenti non leggono i messaggi, tanto meno provano a trasmetterli al supporto (ho visto messaggi di errore che venivano tagliati e incollati dall'usato e poi redatti prima di essere inviati con il commento successivo che sembrava un sacco di informazioni e non avrei potuto desiderarle tutte, quindi ne hanno rimosso casualmente una parte.

E ammettiamolo, con troppi (non tutti ma troppi) i programmatori di prossima generazione, se è più lavoro e non aggiunge flash, non ne vale la pena ...

Ultima nota: se un messaggio di errore include un codice di errore / ritorno, mi sembra che da qualche parte nei moduli eseguiti ci dovrebbe essere una riga che legge qualcosa come "se la condizione restituisce valore-codice" e la condizione dovrebbe dirti perché il codice di ritorno si è verificato. Questo sembra un semplice approccio logico, ma per la mia vita, PROVA a farti dire da Microsoft cosa è successo quando un aggiornamento di Windows non è riuscito su CODICE 80241013 o su un altro identificatore univoco. Kinda triste, no?

Mentre sono d'accordo che le eccezioni dovrebbero contenere quante più informazioni possibili, o almeno essere meno generiche. Nel caso tabella non trovato, il nome della tabella sarebbe carino.

Ma sai di più su cosa stavi cercando di fare nel punto nel codice in cui hai ricevuto l'eccezione. Anche se spesso non puoi fare molto per correggere la situazione quando qualcosa va storto in una libreria al di fuori del tuo controllo, puoi aggiungere molte più informazioni utili su quale situazione è andata storta.

Nel caso di tabella non trovata, non ti sarà di grande aiuto se ti viene detto che la tabella che non può essere trovata si chiama STUDENTI, perché non hai una tabella del genere e quella stringa non è in nessun punto del tuo codice.

Ma se catturi l'eccezione e la ripeti con l'istruzione SQL che stavi tentando di eseguire, starai meglio, poiché si scopre che hai provato a inserire un record con il campo del nome che è Robert '); DROP TABLE STUDENTS; (C'è sempre un xkcd!)

Quindi, per combattere le eccezioni tutt'altro che informative: prova a catturare e rilanciare con maggiori informazioni specifiche su ciò che stavi cercando di fare.

Dovrei probabilmente aggiungere, affinché questa sia più una risposta sul perché nella domanda, che un probabile motivo per cui l'attenzione dei creatori delle biblioteche non è stata rivolta a migliorare i messaggi di eccezione, è che non sanno perché qualcosa è stato provato che non è riuscito, quella logica è nel codice chiamante.

Per dare una risposta leggermente diversa: il codice offensivo è stato probabilmente fatto su specifica:

• La funzione riceve X e restituisce Y
• Se X non è valido, genera l'eccezione Z

Aggiungi la pressione per consegnare esattamente alle specifiche (per paura di essere rifiutato in fase di revisione / test) in un tempo minimo e con il minimo sforzo, quindi hai la tua ricetta per un'eccezione della libreria completamente conforme e inutile.

Le eccezioni hanno un costo specifico per lingua e implementazione.

Ad esempio, sono richieste eccezioni C ++ per distruggere tutti i dati viventi tra il lancio del frame di chiamata e il frame di cattura, e questo è costoso. Pertanto, i programmatori non desiderano utilizzare molto le eccezioni.

In Ocaml, il lancio di eccezioni è veloce quasi quanto una C setjmp(il suo costo non dipende dal numero di frame di chiamata attraversati), quindi gli sviluppatori possono usarlo molto (anche per casi non eccezionali, molto comuni). Al contrario, le eccezioni C ++ sono abbastanza pesanti, quindi probabilmente non le userai molto come faresti in Ocaml.

Un esempio tipico è una ricerca o esplorazione ricorsiva che può essere "fermata" all'interno di una ricorsione abbastanza profonda (ad esempio, trovare una foglia in un albero o una funzione di unificazione). In alcune lingue è più veloce (quindi più idiomatico) propagare quella condizione a ogni chiamante. In altre lingue, lanciare un'eccezione è più veloce.

Quindi, a seconda del linguaggio (e delle abitudini degli sviluppatori che lo utilizzano), un'eccezione potrebbe portare molti dettagli utili, o al contrario essere utilizzata come un salto non locale rapido e trasportare solo i dati molto utili.

Cosa ti fa pensare che il valore dell'indice o l'intervallo richiesto o il nome della tabella sia un dettaglio utile, ad eccezione?

Le eccezioni non sono un meccanismo di gestione degli errori; sono un meccanismo di recupero .

Il punto delle eccezioni è di passare al livello del codice in grado di gestire l'eccezione. Ovunque che livello è, o si dispone le informazioni necessarie, o non è rilevante. Se ci sono informazioni che ti servono, ma non hai accesso immediato a, non stai gestendo l'eccezione al livello appropriato.

L'unica volta in cui riesco a pensare a dove potrebbero essere utili informazioni aggiuntive è al livello più alto assoluto della tua applicazione in cui si blocca ed emette un dump di errore; ma non è compito dell'eccezione accedere, compilare e archiviare queste informazioni.

Non sto dicendo che puoi semplicemente mettere "getta nuova eccezione" ovunque e chiamarlo buono, è possibile scrivere eccezioni sbagliate. Ma includere informazioni irrilevanti non è necessario per usarle correttamente.