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

29

Si continuano a stupisce me che, in questo giorno ed età, i prodotti che hanno anni di utilizzo sotto la cintura, costruiti da team di professionisti, ancora fino ad oggi - non riescono a fornire i messaggi di errore utile per l'utente. In alcuni casi, l'aggiunta di solo un piccolo pezzo di informazioni extra potrebbe far risparmiare ore all'utente.

Un programma che genera un errore, lo ha generato per un motivo. Ha tutto a sua disposizione per informare l'utente il più possibile, perché qualcosa non ha funzionato. Eppure sembra che fornire informazioni per aiutare l'utente sia una priorità bassa. Penso che questo sia un grande fallimento.

Un esempio è di SQL Server. Quando si tenta di ripristinare un database in uso, giustamente non lo consente. SQL Server conosce quali processi e applicazioni vi accedono. Perché non può includere informazioni sui processi che stanno utilizzando il database? So che non tutti passano un Applicatio_Nameattributo sulla loro stringa di connessione, ma anche un suggerimento sulla macchina in questione potrebbe essere utile.

Un altro candidato, anche SQL Server (e mySQL) è il delizioso string or binary data would be truncatedmessaggio di errore ed equivalenti. Molte volte, una semplice lettura dell'istruzione SQL che è stata generata e la tabella mostra quale colonna è il colpevole. Questo non è sempre il caso, e se il motore di database ha rilevato l'errore, perché non può farci risparmiare quel tempo e ci dice solo quale dannata colonna era? In questo esempio, potresti sostenere che potrebbe esserci un colpo di scena nel controllarlo e che ciò impedirebbe lo scrittore. Bene, lo comprerò. Che ne dici, una volta che il motore di database sa che c'è un errore, fa un rapido confronto dopo il fatto, tra i valori che sarebbero stati memorizzati, rispetto alle lunghezze delle colonne. Quindi visualizzalo per l'utente.

Anche gli orribili adattatori di tabelle di ASP.NET sono colpevoli. Le query possono essere eseguite e si può dare un messaggio di errore che dice che un vincolo da qualche parte viene violato. Grazie per quello È ora di confrontare il mio modello di dati con il database, perché gli sviluppatori sono troppo pigri per fornire anche un numero di riga o dati di esempio. (Per la cronaca, non avrei mai usato questo metodo di accesso ai dati per scelta , è solo un progetto che ho ereditato!).

Ogni volta che lancio un'eccezione dal mio codice C # o C ++, fornisco all'utente tutto ciò che ho a portata di mano. È stata presa la decisione di lanciarlo, quindi più informazioni posso dare, meglio è. Perché la mia funzione ha generato un'eccezione? Cosa è passato e cosa ci si aspettava? Mi ci vuole solo un po 'di più per inserire qualcosa di significativo nel corpo di un messaggio di eccezione. Cavolo, non fa altro che aiutarmi mentre mi sviluppo, perché so che il mio codice genera cose significative.

Si potrebbe sostenere che i messaggi di eccezione complicati non dovrebbero essere visualizzati all'utente. Anche se non sono d'accordo con questo, è un argomento che può essere facilmente placato avendo un diverso livello di verbosità a seconda della tua build. Anche allora, gli utenti di ASP.NET e SQL Server non sono i tuoi utenti tipici e preferirebbero qualcosa di pieno di verbosità e informazioni gustose perché possono rintracciare i loro problemi più velocemente.

Perché gli sviluppatori pensano che sia giusto, al giorno d'oggi, fornire la minima quantità minima di informazioni quando si verifica un errore?

E '2011 ragazzi, vieni su .

design exceptions error-messages

— Moo-Juice
fonte

11

Caspita, è abbastanza rant.

— George Marian,

3

@ George, puoi dire che ho appena trascorso molto tempo a rintracciare qualcosa che davvero avrebbe potuto essere risolto più velocemente dato un errore corretto? :)

— Moo-Juice

4

Suggerisco respiri profondi, forse yoga e meditazione. :) (Detto questo, so esattamente come ti senti.)

— George Marian,

2

+1 - "I dati stringa o binari verrebbero troncati" mi fa sempre impazzire!

— k25,

22

Mentre ci sono molti esempi di cattivi messaggi di errore che semplicemente non dovrebbero essere, devi tenere presente che non è sempre possibile fornire le informazioni che desideri vedere.

Esiste anche la preoccupazione di esporre troppe informazioni, il che può indurre gli sviluppatori a sbagliare dal punto di vista della cautela. (Ti prometto che il gioco di parole non era previsto, ma non lo rimuovo ora che l'ho notato.)

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

— George Marian
fonte

+1 Non ho nemmeno pensato all'aspetto del sovraccarico di informazioni.

— Ryan Hayes,

Nel mio post ho spiegato che posso capire perché alcuni ritengono che la verbosità nei confronti di un utente finale possa essere inutile per loro. Ma stai dicendo che gli utenti finali di un'API (adattatori di ASP.NET ag) o di un motore di database (SQL Server) non vogliono errori dettagliati? Qualcosa che ci risparmierebbe potenzialmente ore di tempo perso? Mi è piaciuto il gioco di parole, comunque :)

— Moo-Juice

1

@George, anche per quanto riguarda il sovraccarico di informazioni e la sua utilità per l'utente finale, ancora una volta vedo un caso per non lanciare una traccia stack completa all'utente di un elaboratore di testi, a meno che non abbiano un momento marrone-pantalone e penso di aver cancellato Internet. Tuttavia, hai fornito un'ottima alternativa con informazioni complesse nel file di registro. Tutto quello che quel messaggio deve fare ora è aggiungere For further information, see log20111701.txt. Questo sarebbe un passo nella giusta direzione.

— Moo-Juice,

2

@moo In definitiva, quello che sto dicendo è che è facile criticare. (Lo so, lo faccio spesso.) Tuttavia, provo a tenere presente che non è necessariamente facile dire quante informazioni si dovrebbero includere in un messaggio di errore. Ci sono molte volte in cui ho dovuto eseguire il back-up e generare informazioni più dettagliate di quanto inizialmente previsto durante il debug. Inoltre, ci sono molte volte in cui un messaggio di errore non è stato utile come avevo previsto durante la sua creazione.

— George Marian,

1

@moo Il nocciolo del problema è che non è sempre ovvio quante informazioni siano utili. Gli esempi forniti sembrano piuttosto ovvi. Tuttavia, non è facile estenderlo al caso generale.

— George Marian,

21

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

Vedono l'applicazione da un'angolazione errata. Sono estremamente consapevoli di ciò che è 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.

— David Thornley
fonte

+1 Per molti tipi di errori Framework / API, parte del problema è che lo sviluppatore della libreria non è in grado di conoscere il contesto. Detto questo, l'OP sembra principalmente preoccupato per "qualcosa non va, ma non ho intenzione di dirti dove, anche se conosco" tipi di messaggi di errore. Immagino sia sicurezza, vero?

— MIA,

8

La visione benefica:

Lo sviluppatore ha lavorato a stretto contatto con il codice e ha lottato per comprendere qualcuno che non aveva la sua comprensione lavorando con esso. Di conseguenza pensano che i messaggi di errore vadano bene, semplicemente non hanno un buon quadro di riferimento in base al quale giudicarli.
I messaggi di errore intelligenti sono in realtà difficili da fare. Non solo scrivendoli, ma devi elaborare tutto ciò che potrebbe andare storto, valutare la probabilità 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 fare un buon caso per il momento di fare questo genere di cose così come il prossimo sviluppatore vorrebbe davvero perché gli errori non si verificano così spesso. Inoltre, se avessi quel tempo extra, non dovresti spenderlo per fermare gli errori piuttosto che segnalarli?

La visione inesplorabile:

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 schiena per la prossima cosa. Capisco questo codice, starò bene, il prossimo alla fine lo risolverà e sarò fuori di qui per allora, 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 successiva - fondamentalmente è in realtà abbastanza difficile e richiede una notevole quantità di sforzi per affrontare qualcosa che probabilmente non accadrà.

— Jon Hopkins
fonte

Capisco da dove vieni in molti casi di utenti finali. Tuttavia, i casi che ho delineato nel mio post originale possono accadere frequentemente durante la scrittura di codice su database. Per quanto riguarda le applicazioni dell'utente finale come un elaboratore di testi o un gioco per computer, in genere non dovrebbero verificarsi errori a meno che non stia succedendo qualcosa di brutto , e anche allora l'errore potrebbe non significare nulla per l'utente finale ( Process Handle Raped By Spawned Injector, Quitting SYstem..... user: "wtf ho fatto?`). Ma nel caso di SQL Server / ASP.NET, penso che si sarebbe potuto fare più sforzo :)

— Moo-Juice,

@ Moo-Juice - Penso che si tratti dell'intera cosa "i messaggi di errore sono difficili". Sotto il cofano ciò che viene effettivamente lanciato nel database una volta che l'ottimizzatore ha fatto la sua cosa ha solo una somiglianza di passaggio con ciò che hai lanciato. Identificare l'errore è una cosa, rintracciare ciò che è accaduto a ciò che è stato superato è un'altra completamente e assolutamente non banale.

— Jon Hopkins,

alcuni casi potrebbero non essere banali. Ho un po 'di codice da qualche parte che rileva l' string/binary dataerrore che estrae tutte le informazioni sulla colonna da detta tabella, esamina i valori passati e mostra quali colonne sarebbero state in violazione. Questo è stato banale. Forse sto scherzando troppo perché i miei esempi di casi sono banali, ma capisco perfettamente che non è sempre così. Come fermare gli iniettori generati dai processi di stupro potrebbe essere difficile :)

— Moo-Juice

6

Sfortunatamente, messaggi di errore più utili costano tempo per gli sviluppatori, che equivale al denaro dell'azienda. I prodotti sono abbastanza costosi da costruire così com'è. Sì, sarebbe fantastico avere messaggi di errore più utili e sono d'accordo che dovrebbero essere inclusi quelli più utili. Tuttavia, è solo un dato di fatto che quando sei sotto una scadenza, e il denaro è in linea, devi tagliare qualcosa. "I messaggi di errore più belli" come possono vederli i gestori, saranno probabilmente la prima cosa da fare.

— Ryan Hayes
fonte

Ah, sì, buon punto. Quella sempre presente preoccupazione per i costi.

— George Marian,

Posso concedere una prospettiva di costo (e dannazione, ciò non significa che mi debba piacere ). Non posso parlare dal punto di vista degli sviluppatori di SQL Server o ASP.NET, ma so che non ci vuole che molto sforzo supplementare per fornire un nome di colonna. Ammetto che, per il mio semplice esempio, potrebbe essere risolto in un'ora. Poi ci sono gli altri 1000 errori che potrebbero essere generati. Ma potrebbero almeno iniziare con quelli comuni :)

— Moo-Juice,

ovviamente non conosco gli interni del server SQL, ma in generale, il più delle volte non hai queste informazioni a portata di mano nel momento in cui viene rilevata la situazione di errore. Una formulazione come "dati stringa o binari" mostra chiaramente che nel sito dell'errore non è nemmeno chiaro se il valore troncato fosse una stringa o un numero ...

— Ichthyo

Ad un certo livello, questo può essere valido, ma lo stesso problema si presenta anche in semplici script perl in cui semplicemente aggiungendo $! al messaggio di errore sarebbe immensamente utile. Scrivere 'die "$ path: $!"' È più economico (in termini di tempo dello sviluppatore) che scrivere "die" Impossibile aprire $ path "'

— William Pursell il

6

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

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

— ThomasW
fonte

è anche peggio: mentre puoi innescare errori in punti molto specifici, al fine di gestire gli errori sei costretto a riassumere diverse possibilità in una classe di situazioni e gestirle con un unico recupero. Questo atto di generalizzazione spesso ti costringe a scartare ancora di più le scarse informazioni aggiuntive sul contesto.

— Ichthyo,

btw ... questo meccanismo porta a un'intera classe di divertenti messaggi di errore - sulla falsariga di "Errore grave -567 nel Modulo nano678: Nessun errore rilevato"

— Ichthyo

4

A volte troppe informazioni possono costituire 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

— StuperUser
fonte

Ho risposto al tuo primo punto consentendo un cambiamento nella verbosità delle eccezioni introdotte nel tuo codice. Il tuo secondo punto è controverso dato che a questo punto si è verificato un errore e la velocità non è più un fattore decisivo (imho). E se la produzione di un messaggio di errore dettagliato richiede un impatto sulle prestazioni PRIMA di generare l'eccezione, sono d'accordo. Spostare quel codice su DOPO che è stata generata l'eccezione. Non vedo nessuno di questi punti come un valido argomento contro i messaggi di errore corretti :)

— Moo-Juice,

È vero, suppongo che puoi cercare le informazioni una volta che è successo qualcosa piuttosto che tenere traccia di ciò di cui potresti aver bisogno. Tuttavia, se ci si trova in loop nidificati, l'acquisizione degli indici / indici potrebbe essere problematica.

— Stuper Utente

-1 per il primo punto con cui non sono d'accordo, +1 per il secondo punto.

— Jon Hopkins,

1

@jon Contrasta un messaggio di errore generico per errori di accesso rispetto a messaggi di errore più specifici che indicano effettivamente cosa è andato storto. ad es. "Impossibile trovare la combinazione nome utente / password" vs "Hai inserito una password errata." / "Quel nome utente non esiste." Mi sembra di ricordare una vulnerabilità in ASP.NET in cui il messaggio di errore era effettivamente utile nel craccare le chiavi di crittografia.

— George Marian,

@George - Sono d'accordo con quell'esempio ma non credo sia diffuso. Dopo aver ottenuto l'accesso a un'applicazione, un certo livello di rischio scompare in quanto si può presumere che la persona sia (a) autorizzata e (b) possa ottenere la maggior parte di ciò che è necessario dall'applicazione effettiva.

— Jon Hopkins,

3

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 dovevano funzionare. Se così non fosse, non sarebbe necessario salvarsi 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 i nostri presupposti. Quando questi controlli di integrità falliscono, sappiamo solo che il piano in qualche modo fallito ...

La tua richiesta - potrebbe sembrare un senso comune dal punto di vista dell'utente - è impossibile da soddisfare, se si considera la realtà di come funziona un sistema del genere. Si richiede una dichiarazione ordinata con informazioni ben organizzate e adeguate aggiunte. Inoltre, chiedi anche che questa presentazione avvenga in un modo che si adatti alla progettazione generale dell'applicazione / gestione. Ovviamente questa informazione esiste da qualche parte nel sistema. Ovviamente esiste anche lì in modo ordinato e ben organizzato (speriamo 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ò verificarsi a vari livelli. Potrebbe essere il sistema che si comporta in fase di esecuzione in modo diverso da quanto pianificato. Ma potrebbe anche essere che l'attuazione effettiva si sia rivelata molto più difficile e diversa nei dettagli rispetto a quanto pianificato, e non vi era alcuna disposizione modificata per gestire questa situazione in modo soddisfacente. Anche questa è una parziale perdita di controllo.

Per mettere in relazione questo con l'esempio concreto che hai dato: se, al momento dell'errore, il nome e il tipo della colonna della tabella fossero noti, e in aggiunta la lunghezza dello spazio richiesto, allora non ci sarebbe alcun motivo per sollevare un errore, no? Potremmo semplicemente risolvere la situazione e procedere come previsto. Il fatto stesso che siamo costretti a sollevare 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 scrivo qui può sembrare evidente e semplice buon senso. Ma in realtà è estremamente difficile da capire. Cerchiamo costantemente di capirlo applicando le categorie morali : come ci deve essere un colpevole, ci deve essere una persona pigra cattiva che non si prende cura del povero utente, ci devono essere uomini d'affari avidi che hanno fatto un calcolo economico. Tutto ciò è completamente diverso dal punto

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

— Ichthyo
fonte

Non sono d'accordo. Sa che qualcosa non va (non può eseguire l'operazione). Sapere che qualcosa non va indica una conoscenza del perché è sbagliato. Questa stringa è troppo grande per quella colonna (o una colonna in quella tabella). Si poteva dirmi, senza molto lavoro. È un dannato motore di database aziendale. Lo sa . Ma non trasmette tali informazioni. Dato che il programmatore può scrivere una query da eseguire dopo che il fatto di scoprirlo mostra che il motore di database potrebbe fare lo stesso. Queste non sono sfaccettature segrete prive di documenti. Solo un pessimo messaggio di errore :)

— Moo-Juice,

eh ... dovresti basare la tua argomentazione sulla logica, non sul pensiero stravagante. Da quando un computer sa qualcosa? Questo non è il cinema di Hollywood. Un programma è una configurazione rigida e predisposta e quando i tuoi presupposti vengono infranti, hai perso il controllo. È davvero così difficile da capire? Un computer non capisce il programma e quindi non può capire quando sta andando storto. Quasi sempre, quando si attiva un controllo di coerenza, l'esecuzione ha già proceduto per migliaia di istruzioni e nessuno sa quali dati sono già stati corrotti. Tutto ciò che puoi fare è limitare il danno

— Ichthyo il

2

Lavoro come ingegnere di supporto per un'azienda di software e spesso vediamo messaggi di errore per noi nuovi. Spesso, quando li rimando al nostro team di sviluppo, devono cercare il messaggio nella fonte dell'applicazione.

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

— glenatron
fonte

1

scusa, è abbastanza poco pratico. Chi sarebbe responsabile della gestione di quel documento indice, per mantenerlo accurato. Poiché qualsiasi documentazione scritta separata dal codice, sarebbe obsoleta e inizierebbe a ottenere una fonte per nuovi errori nel momento stesso in cui è scritta.

— Ichthyo,

Al contrario, questo è il tipo di cosa che uno script potrebbe estrarre dal codice sorgente, se ogni errore avesse un numero univoco, e la descrizione di ciascuno fosse anche nel codice sotto forma di un commento (appositamente formattato) o come un stringa. Quindi il documento verrebbe generato automaticamente con ogni build. Il messaggio estratto potrebbe quindi essere un po 'più dettagliato di qualsiasi cosa tu voglia vedere all'utente finale. Non è una cattiva idea!

— Jeanne Pindar,

non è necessario uno script per questo - molti sistemi di runtime possono registrare il numero di riga o alcune informazioni simili. Sfortunatamente questo non aiuta con il problema originale, perché in questo modo sappiamo solo dove è stata rilevata un'eccezione ma non sappiamo cosa è andato storto . Scoprire che quest'ultimo si chiama debugging - in pratica si tratta di un compito più o meno noioso e ad alta intensità di lavoro svolto dagli umani.

— Ichthyo,

Sono con @Jeanne - abbastanza semplice da incorporare nel codice o avere un indice centrale nel codice con il codice di errore e la loro interpretazione. Una volta sai dove è stata rilevata un'eccezione che potrebbe essere sufficiente per dirti che c'è un problema con l'ambiente da qualche parte piuttosto che qualcosa nel codice che deve essere inseguito.

— glenatron,

2

Il problema che stai vedendo lì è in realtà uno degli effetti collaterali della corretta incapsulamento e nascondere le informazioni.

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

Quindi, mentre uno sviluppatore è seduto e codifica, per esempio, il bit che ripristina un file di database, il suo modello mentale viene riempito interamente con i bit che circondano l'atto di ripristinare un file di database. Deve (e immagino, non ho scritto questo codice) leggere un file, controllare le proprietà, leggere le versioni, eseguire il backup dei dati esistenti, scegliere una strategia di unione / sovrascrittura, ecc. Molto probabilmente, se c'è anche un passaggio considerazione all'interfaccia utente, è nella stringa di errore che scrive in un gestore di eccezioni. Qualcosa di simile a:

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

In questo esempio, le informazioni utili di cui ti stai chiedendo in termini di processi che potrebbero utilizzare il file, o anche altri thread nel DB, sono completamente al di fuori dell'ambito (programmaticamente). Potrebbero esserci centinaia di classi che si occupano di file DB; importare in tali classi informazioni su ogni altro processo usando i file o funzionalità per accedere al file system e guardare gli altri processi in esecuzione (supponendo che tali processi siano anche su QUESTA macchina) comporterebbe ciò che è noto come un'astrazione che perde ; c'è un costo diretto in produttività.

Ecco come questi tipi di errori possono persistere nei giorni nostri. Ovviamente, POTREBBERO essere risolti; ma in molti casi, ci sono molte più spese generali di quanto si pensi ragione) e il costo è tutt'altro che banale.

— GWLlosa
fonte

@GWLlosa, questa è un'ottima risposta e una che non avevo considerato. Detto questo (e non posso fornire un esempio di codice completo qui), quando ottengo quell'IOException, prima di lanciare il mio GenericException, potrei 1) Chiedere al ProcessesSottosistema un elenco di processi. 2) Chiedi a ciascun processo quale database stanno utilizzando. 3) Abbina il processo al database assegnato a quello che sto cercando di sovrascrivere, 4) genera DatabaseInUse(dbName, processName, applicationNameun'eccezione. :)

— Moo-Juice,

1

Certamente possibile; ma il codice per abbinare il DB al processo (specialmente attraverso la rete) potrebbe essere complicato / lento / soggetto a errori, il che potrebbe provocare una frustrazione aggiuntiva ("Sto solo cercando di ripristinare il locale (* #% ^! % file !!!! PERCHÉ CURA CHE LE AZIONI DELLA RETE NON SONO ACCESSIBILI! ??!?! ")

— GWLlosa,

1

@ Moo-Juice: quello che proponi sembra abbastanza ingenuo. In un enorme ambiente multithread come un database non puoi semplicemente contattare un servizio globale per ottenere un elenco di "all xyz". Anche per parlare con qualche altro servizio in un altro thread, hai bisogno di un blocco, che potrebbe peggiorare il deadlock dell'intero sistema, potrebbe corrompere altri dati o almeno potrebbe causare ulteriori errori, che devi gestire anche in seguito ....

— Ichthyo,

1

Quell'esempio è davvero molto istruttivo: in genere in un tale gestore catch, non si può nemmeno dire con certezza quale parte del blocco try ha avuto esito negativo (di solito ci sono più parti che potrebbero causare una IOException). Oltre a ciò, è molto probabile che in quella posizione non sia possibile dire il nome del file, per non dire quale tabella logica corrisponde a questo file.

— Ichthyo,

@Ichthyo, senza offesa ma non credo che sia affatto ingenuo. Non sto chiedendo al motore di database di bloccare il sistema per dirmi quale processo ha ancora un handle per un database. Non sto chiedendo di fermare l'intera impresa. Se ha bisogno di darmi una risposta semplice, ciò mostra in primo luogo un difetto di progettazione fondamentale del server di database. Ricorda che dovrebbe essere progettato per restituire le informazioni pertinenti nel modo più rapido possibile. Per fargli la domanda "chi?" davvero non dovresti essere così ingenuo come dici :)

— Moo-Juice,

2

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

È stata tentata l'interpretazione di dati insignificanti

— smirkingman
fonte

+1, assolutamente fantastico! È il tipo di errore che ti fa venire voglia di mollare e andare a allevare polli alle Figi.

— Moo-Juice,

in effetti, questo messaggio di errore è accurato al 100%: se si desidera un messaggio più amichevole con più suggerimenti, è necessario inserire alcune ipotesi ed euristica; in questo modo aggiungi la possibilità di messaggi di errore fuorvianti ..

— Ichthyo,

0

Credo che la maggior parte dei messaggi di errore siano in realtà dichiarazioni di codice / printf di debug glorificate e orientate al programmatore.

Scrivere messaggi di errore orientati all'utente significa sapere chi è l'utente e anticipare ciò che vorranno sapere. Durante la scrittura del codice, uno sviluppatore è più propenso a scrivere un messaggio di errore utile a se stesso, sia per il debug del codice che sta scrivendo al momento, sia per i casi d'uso noti o predominanti.

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

Naturalmente, il controllo e la verifica della gestione degli errori è spesso considerato una priorità bassa, fintanto che vengono gestiti (ovvero rilevati) errori ed eccezioni, non viene data molta enfasi ad esso. È un luogo mentalmente poco gratificante della base di codice per gli sviluppatori o il QA da valutare, poiché le condizioni di errore hanno spesso una connotazione negativa (cioè errore o fallimento) ad essi associata.

— mctylr
fonte

0

Penso che il motivo sia che la segnalazione / gestione degli errori viene sempre effettuata come ripensamento . Anche quando non sono del tutto ripensati, sono per lo più cittadini di seconda classe nel design generale.

Il software moderno di solito è composto da più livelli. Quando la logica di segnalazione degli errori viene stabilita in fretta senza pensarci troppo, spesso è difficile raccogliere tutte le informazioni necessarie per presentare utili messaggi di errore.

Ad esempio, l'errore viene rilevato nel back-end, ma per comporre un messaggio di errore completo sono necessarie alcune informazioni dai livelli superiori. La maggior parte dei buoni messaggi di errore richiede informazioni da quasi tutti i livelli (per darci una visione completa di ciò che è accaduto nel sistema). Il messaggio di errore ideale sarebbe "OK, prima abbiamo ricevuto una stringa, poi è passata attraverso il parser che ha dato qualcosa di divertente, potresti voler guardare lì. Comunque, la cosa è stata trasmessa più in basso ..."

Farlo richiederebbe spesso un accoppiamento non necessario se il meccanismo di segnalazione degli errori non era cittadino di prima classe durante la fase di progettazione. Immagino che la maggior parte delle persone ritenga che ci sia 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!").

— kizzx2
fonte