Esiste un termine per l'anti-pattern di gestione degli errori di scartare tutte le informazioni disponibili e solo l'errore di restituzione?

Question

Esiste un termine per l'anti-pattern di gestione degli errori di scartare tutte le informazioni disponibili e solo l'errore di restituzione?

#1 da (9 voti)
#2 da (2 voti)

4

Di tanto in tanto (purtroppo troppo spesso) devo correggere codice come questo:

// C++ code
bool anyOldFunction(Param p) {
  try {
  ...
  if(some_condition_here) {
    handleErrorX();
    return false;
  } else if(other_condition) {
    return false; // (*stackexchange question comment*) Apparently no additional error action taken here
  }
  ...
  return true;
  } catch(...) {
    // (*old comment*) Catch all possible error (FroobleFub and BrabbleBub can happen)
    return false;
  }
}

Quindi, l'implementatore originale aveva effettivamente alcuni indicando quali eccezioni potevano essere lanciate (sebbene l'elenco non fosse esaustivo) ma non aveva idea di come comportarsi in maniera decente e scartasse tutte le informazioni che poteva sono usciti dagli oggetti di eccezione, lasciando il codice di chiamata / il contesto di chiamata non più saggio.

Esiste un nome per questo anti-pattern? (Se anti-pattern è davvero.)

anti-patterns error-handling c++ exceptions

posta Martin Ba 05.09.2011 - 11:30

fonte

2 risposte

2

risposta diretta alla tua domanda: io di solito la sento chiamare "deglutire" o "mangiare l'errore"

Risposta indiretta: non è sempre un modello indesiderabile. A volte questo schema è desiderabile quando non si vuole assolutamente che il dettaglio dell'errore lasci il livello / classe / funzione / qualsiasi cosa si trovi attualmente. L'accesso ai dati era (è ancora in alcuni casi) famoso per includere informazioni sensibili nei dettagli delle eccezioni. È stato abbastanza comune in diversi lavori precedenti vedere blocchi di eccezioni come quello in modo che i dettagli interni non venissero esposti solo da qualcuno che rende una risorsa non disponibile. A volte ho sentito persone chiamare queste eccezioni sicure o fallimento sicuro.

L'altro posto dove vedo ancora quel pattern è dove il dettaglio dell'eccezione non è importante. Ad esempio, quando si interagisce con una libreria esterna che non ha un buon modo per controllare le precondizioni o bloccare una variabile variabile, ad esempio, a volte basta effettuare la chiamata e se si verificano eccezioni si sa che il valore non è disponibile. Se hai un altro modo per continuare, è più efficiente consumare l'errore il più basso possibile e passare un flag piuttosto che srotolare lo stack ad ogni livello con un intero casino di blocchi catch.

Potresti sicuramente cambiarlo (e tutti i suoi metodi di chiamata per includere ulteriori blocchi catch e non fare affidamento sul flag di ritorno), ma a meno che tu non abbia qualcosa di significativo che puoi fare con i dettagli delle eccezioni al prossimo livello superiore e non c'è il rischio di mostrare tutte le possibili eccezioni e lo stack business tutto ciò che stai facendo è creare più posti dove devi codificare i blocchi di catch lenti.

risposta data 06.09.2011 - 01:39

fonte

Leggi altre domande sui tag anti-patterns error-handling c++ exceptions

Come posso far lavorare meglio i programmatori sul codice condiviso con i test Passaggio da uno sviluppo su misura a una casa di sviluppo COTS

score 9 · Accepted Answer

"Exception Swallowing" (una discussione sul blog di Phil Haack: link )

o

"Error Hiding" : link

Mentre si sta codificando in C ++ e non sono sicuro dei suoi meccanismi durante la gestione delle eccezioni, il problema principale con la deglutizione delle eccezioni nel codice gestito .NET è che se viene retrocesso o se viene creata una nuova eccezione senza l'originale incluso , la traccia dello stack per la causa originale dell'errore non è inclusa, il che rende il debug un po 'più difficile, come hai discusso nella tua domanda.