Perché gli errori di nesting o piggybacking all'interno degli errori sono in generale cattivi?

Question

Perché gli errori di nesting o piggybacking all'interno degli errori sono in generale cattivi?

#1 da (6 voti)

4

Perché gli errori di annidamento o piggybacking all'interno degli errori sono in generale cattivi?

A me sembra male intuitivamente, ma sono sospettoso in quanto non riesco ad articolare adeguatamente il motivo per cui è male. Questo può essere perché non è in generale cattivo e che è solo cattivo in casi specifici. Perché è dannoso progettare la gestione degli errori / delle eccezioni in questo modo.

L'istanza specifica è quella di un servizio REST. Alcuni desiderano utilizzare gli errori http (in particolare la risposta 500) come un modo per indicare qualsiasi problema con istanze specifiche di una risorsa. Un esempio di una risorsa di istanza in questo caso sarebbe:

  http://server/ticket/80 # instance
  http://server/ticket # not an instance

Quindi questo è il comportamento che viene proposto.

Se ticket 80 non esiste, restituisci un codice di risposta http di 500 . All'interno del corpo dell'errore restituisce l'errore "reale" come ulteriore codice di errore e descrizione.
Se la risorsa ticket non esiste, restituisce un codice di risposta 404.

design error-handling errors design-patterns rest

posta dietbuddha 01.10.2012 - 21:08

fonte

1 risposta

Leggi altre domande sui tag design error-handling errors design-patterns rest

Uso appropriato di SQL CLR Best practice per rappresentare SQL nel codice sorgente del programma

score 6 · Accepted Answer

Il problema con gli errori di piggy-backing è che quando si verifica, non si sa quale dei potenziali errori è il vero problema.

Nel tuo caso, restituire un codice di errore http di 500 potrebbe significare:

il ticket non esiste
c'è un problema con l'accesso al ticket n. 80
c'è un problema nel richiamare e inserire il ticket # 80 con le informazioni

In generale, una tecnica a piggyback è pigra. Lazy può essere buono, ma può anche essere veramente pessimo. In questo caso, voterò per quest'ultimo.

Questo è pigro male perché quando (non se) quell'errore si verifica, dovrai raddoppiare o triplicare la quantità di lavoro nel capire cosa è veramente andato storto. Su un sistema abbastanza piccolo, potrebbe essere tollerabile. In un ambiente ad alto volume o marginalmente stabile, l'approccio pigro è una buona ricetta per un serio mal di testa.

L'approccio giusto è quello di codificare una pagina di errore che indica

qualcosa è andato storto
il sistema ha rilevato proattivamente che qualcosa è andato storto (che non è lo stesso del primo elemento)
le informazioni diagnostiche sono state inviate a un account sysad o presentano le informazioni diagnostiche da fornire nella chiamata problematica.

Se eri molto impegnativo per il tempo di sviluppo, almeno utilizza un codice di errore http molto meno utilizzato, in modo da poter aggirare alcuni dei problemi relativi alla risoluzione dei problemi.