Qual è la risposta corretta al messaggio di errore scadente?

O aggiustalo tu stesso o segnala un errore al programmatore responsabile di ciò per risolverlo.

Inoltre ci sono due odori di codice in questo:

• Nessun framework di registrazione.
• Il codice non dovrebbe uscire bruscamente.

È importante avere il fumetto dell'eccezione nel metodo principale, averlo registrato correttamente e poi uscire. Ciò consente al codice upstream di avvolgere correttamente le cose: chiude i file, svuota i buffer, rilascia le risorse di sistema, ecc.

Una potenziale reazione sana dopo aver superato il disgusto (ed è normale sentirsi disgustato):

È possibile che il programmatore che lo ha fatto sia stato sottoposto a un periodo di tempo così grave da essere grato solo per avere il tempo di essere in grado di segnalare qualsiasi stringa di errore? Il programmatore potrebbe desiderare di avere il tempo di lucidare tutto, ma ha fatto il meglio che potevano in circostanze molto difficili.

Ho visto un sacco di codice in cui lavoro che è terribile e brutto, ma è stato scritto da persone molto intelligenti che cercano di ottenere l'azienda attraverso il prossimo ciclo salariale. Sono solo grato che sia stato scritto perché il loro completamento ha permesso di avere un lavoro in cui posso lamentarmi di quanto sia pessimo il codice originale:)

Mentre è difficile scusare la gestione degli errori con questa piccola informazione, la realtà è che la gestione degli errori dell'ambito è in realtà piuttosto complicata.

Troppo poco e si finisce per non riuscire a risolvere anche i problemi più dritti, troppo e si finisce con i registri che girano prima che si possa arrivare a loro, riempire i server e dove scrivere la gestione degli errori richiede quanto scrivere il codice senza avere alcuna idea se sarà persino problematico (seriamente, ho visto il codice che scarica ogni variabile su ogni chiamata di funzione ma che non è mai andata molto male).

In questo esempio potrebbe valere la pena chiedere da quanto tempo è in circolazione questo codice e cosa fa. Se è in giro da 10 anni e continua a farlo, probabilmente è un segnale che il codice è in realtà privo di problemi e che la gestione degli errori non è necessaria.

E a seconda di ciò che sta facendo potrebbe essere che o non hai bisogno di sapere della natura dell'errore (perché tutto quello che ti interessa è che ha fallito ed è irrilevante perché) o che il codice lo fa come specifico cosa che chiunque lo capisca sarà in grado di indovinare cosa è successo il 99% delle volte senza ulteriori informazioni.

In definitiva hai ragione, in pratica non c'è più lavoro per inserire le informazioni extra e dovrebbe succedere, ma stai dicendo che non hai rispetto per loro.

Probabilmente è un caso di inesperienza o di pressione del tempo, o di scrivere qualcosa di veloce e sporco che pensavano potesse essere eseguito una volta e in qualche modo finito in produzione ancora un decennio dopo. Sono tutti un po 'schifosi ma siamo stati tutti lì e abbiamo lasciato che il programmatore che non ha mai scoperto un codice meno perfetto abbia lanciato la prima pietra.

In termini di specifiche, l'ho risolto e forse gentilmente spedisco per posta la squadra dicendo che l'hai notato e non sarebbe stato meglio e non c'è più lavoro per includere il messaggio standard (incluso un buon esempio di codice in modo che non possano 'anche bisogno di cercare su).

Ma su una nota più ampia ottenere correttamente la gestione degli errori è più difficile di quanto sembri.

Penso che tu sia troppo maleducato qui. Soprattutto perché il tuo suggerimento (incluso il messaggio di errore del sistema) può essere criticato. Non so come avvenga in Python, ma in .NET Framework, i messaggi di eccezione non dovrebbero essere visualizzati all'utente finale. Sono scritti per sviluppatori e solo per loro. Ci sono almeno tre ragioni per questo:

• La lingua di .NET Framework potrebbe essere diversa dalla lingua dell'interfaccia utente (incluso quando la lingua dell'interfaccia utente è configurabile dall'utente).
• I messaggi di eccezione a volte sono spaventosi o non utili per un utente finale (ti piacerebbe mostrare al tuo utente qualcosa del tipo: "Riferimento dell'oggetto non impostato su un'istanza di un oggetto"?).
• L'invio di un messaggio di eccezione esatto non è molto sicuro.

In sua risposta , Thorbjørn Ravn Andersen indica i due problemi più importanti con il codice: nessuna registrazione e uscita improvvisa. Ma per quanto riguarda il messaggio di errore stesso?

Direi che non è così male rispetto agli altri. Vedo un sacco di messaggi strani, sbagliati, inutili anche nei prodotti commerciali più popolari. Esempi:

• Quando ci occupiamo dei nomi dei file che superano i 259 caratteri, Microsoft Word ci dice una storia molto utile che il nostro lettore di floppy è troppo piccolo (su una macchina in cui non vi è alcuna unità floppy) e suggerisce, indovina cosa? .. .che aggiorniamo il nostro antivirus.

• Quando succede qualcosa di sbagliato in Visual Studio, a volte dice che, beh, è successo qualcosa di sbagliato, ma non si preoccupa di dirci cosa, e non vuole nemmeno dire dove sono i file di registro (sono quegli errori registrati, a proposito?).

• Sul mio vecchio telefono, quando provo a inviare email, mi dice qualcosa come "Operazione fallita". Oh, grazie per questi dettagli, ora so esattamente cosa c'era che non va!

• ecc.

DailyWTF ha anche molti esempi di tali messaggi di errore. Compreso messaggi pessimistici come "Errore: successo".

In molti casi, puoi vedere qualcosa come:

try
{
    // Thousands of lines here (hopefully not in the same method).
}
catch (Exception) // After all, who cares about *what* is exactly the exception?
{
    MessageBox.Show(@"Something went wrong. Please restart your application.
If you see this message again, contact your administrator.");

    // And yes, we don't want to be polite, don't want to tell what's wrong,
    // but want to suck administrators by telling them that they must contact
    // themselves.
}

Se inserisci un messaggio di errore, se non è scritto correttamente (perché non hai tempo, o qualsiasi cosa), almeno:

• Non inserire suggerimenti stupidi, come "contatta l'amministratore",
• Rendi ricercabile l'errore su Internet (compreso un numero di errore che può essere d'aiuto), o almeno assicurati che ci sia un solo errore in un contesto specifico.
• Assicurati che l'utente possa segnalare l'errore . Riesci a risolvere rapidamente la segnalazione di bug se dice:

Bug 1024: I think I've found a bug. When working with your great and user friendly application, sometimes, it randomly displays "The application encountered a fatal error." message. Can you solve it, please?

Penso che il mio numero sia all'incirca lo stesso (47 milioni, dare o prendere) di correre verso un codice C # piuttosto equivalente:

try
{
    // Tricksy code be here.
    return true;
}
catch (Exception ex)
{
    Logger.Error("This error occurred: " + ex.Message);
    return false;
}

Quindi, nel nostro registro, ci ritroviamo con un numero di "riferimento all'Oggetto non troppo utile" non impostato su un'istanza di un oggetto "semplicemente seduto lì senza altro contesto. Quanto è difficile effettivamente digitare LESS e farlo essere:

    Logger.Error("This error occurred: " + ex);

Informazioni molto più utili per gli sviluppatori.

Ora come alla tua seconda domanda: lo sviluppatore è un novizio? Forse sì forse no. Ma certamente lo sviluppatore non ha pensato a cosa potrebbe essere necessario per eseguire la ricostruzione forense di un errore.