Errore durante la verifica dell'overkill?

Question

Che controllo degli errori fai? Che controllo degli errori è effettivamente necessario? Abbiamo davvero bisogno di verificare se un file è stato salvato con successo? Non dovrebbe funzionare sempre se è testato e funziona bene dal primo giorno?

Mi trovo a controllare gli errori per ogni piccola cosa e la maggior parte delle volte si sente eccessivo. Cose come controllare per vedere se un file è stato scritto correttamente in un file system, controllando per vedere se un'istruzione di database fallisce ....... non dovrebbero essere queste cose che funzionano o no?

Quanto controllo degli errori si esegue? Ci sono elementi di controllo degli errori che lasci perché ti fidi che funzionerà?

Sono sicuro che mi ricordo di aver letto da qualche parte qualcosa sulla falsariga di "non testare per cose che non accadrà mai" ..... non riesco a ricordare la fonte però.

Quindi, tutto ciò che potrebbe fallire può essere controllato in caso di fallimento? O dovremmo semplicemente fidarci di quelle operazioni più semplici? Ad esempio, se possiamo aprire un file, dovremmo controllare se la lettura di ogni riga è fallita o no? Forse dipende dal contesto all'interno dell'applicazione o dell'applicazione stessa.

Sarebbe interessante ascoltare quello che fanno gli altri.

AGGIORNAMENTO: Come esempio rapido. Salvo un oggetto che rappresenta un'immagine in una galleria. Quindi salverò l'immagine sul disco. Se il salvataggio del file fallisce, dovrò visualizzare un'immagine anche se l'oggetto pensa che ci sia un'immagine. Potrei controllare se il salvataggio dell'immagine non è riuscito su disco e quindi eliminare l'oggetto, o in alternativa avvolgere l'immagine salvata in una transazione (unità di lavoro), ma può diventare costoso quando si utilizza un motore di database che utilizza il blocco della tabella.

Grazie,

James.

Answer 1

Generalmente seguo queste regole.

1. eccessivamente convalidano l'input dell'utente.
2. Convalida API pubbliche.
3. Utilizzare gli asserti che vengono compilati dal codice di produzione per tutto il resto.

Answer 2

se si esaurisce lo spazio disponibile e si prova a scrivere il file e non si verificano errori, l'applicazione si bloccherà silenziosamente o con messaggi stupidi. odio quando vedo questo in altre app.

Answer 3

non sto affrontando l'intera domanda, solo per questa parte:

così dovrebbe tutto ciò che potrebbe eventualmente fail essere controllato per il fallimento? Oppure dovremmo semplicemente fidarci di quelle più semplici operazioni ?

Mi sembra che il controllo degli errori sia più importante quando il passaggio NEXT è importante. Se la mancata apertura di un file consentirà di perdere definitivamente i messaggi di errore, allora questo è un problema. Se l'applicazione semplicemente morirà e darà all'utente un errore, allora considererei un diverso tipo di problema. Ma morire in silenzio o appendere in silenzio è un problema che dovresti davvero fare del tuo meglio per codificarti.Quindi, se qualcosa è una "semplice operazione" o non è irrilevante per me; dipende da cosa succederà dopo, o quale sarebbe il risultato se fallisse.

Answer 4

Per quanto riguarda il tuo esempio ...

risparmio un oggetto che rappresenta un'immagine in una galleria. Quindi salverò l'immagine sul disco. Se il salvataggio del file fallisce, visualizzerò un'immagine [no] anche se l'oggetto pensa che ci sia un'immagine. Potrei controllare se il salvataggio dell'immagine non è riuscito su disco e quindi eliminare l'oggetto, o in alternativa avvolgere l'immagine salvata in una transazione (unità di lavoro), ma può diventare costoso quando si utilizza un motore di database che utilizza il blocco della tabella.

In questo caso, consiglio salvare l'immagine su disco primo prima di salvare l'oggetto. In questo modo, se l'immagine non può essere salvata, non è necessario provare a ripristinare la galleria. In generale, le dipendenze dovrebbero essere scritte su disco (o inserite in un database) prima.

Come per il controllo degli errori ... controllare gli errori che hanno senso. Se fopen() fornisce un ID di file e non si verifica un errore, in genere non è necessario verificare la presenza di fclose() in tale ID file che restituisce "ID file non valido". Se, tuttavia, l'apertura e la chiusura dei file sono attività disgiunte, potrebbe essere una buona idea controllare l'errore.

Answer 5

Questa potrebbe non essere la risposta che stai cercando, ma c'è sempre una risposta "giusta" se guardata nel contesto completo di ciò che stai cercando di fare.

Se stai scrivendo un prototipo per uso interno e se ottieni lo strano errore, non importa, quindi stai sprecando tempo e denaro dell'azienda aggiungendo il controllo extra.

D'altra parte, se si sta scrivendo software di produzione per il controllo del traffico aereo, il tempo extra per gestire ogni errore immaginabile può essere ben speso.

Lo vedo come un compromesso: un tempo aggiuntivo dedicato alla scrittura del codice di errore rispetto ai vantaggi di aver gestito quell'errore se e quando si verifica. Gestire religiosamente ogni errore non è necessario IMO ottimale.