È sbagliato aggiungere campi alle eccezioni? Ho un problema che succede e sto pensando di aggiungere informazioni considerevoli a un'eccezione, ma suona strano: un'eccezione con i getter.
Cosa ne pensi?
È sbagliato aggiungere campi alle eccezioni? Ho un problema che succede e sto pensando di aggiungere informazioni considerevoli a un'eccezione, ma suona strano: un'eccezione con i getter.
Cosa ne pensi?
Cosa c'è che non va? Le eccezioni sono ancora oggetti, vengono semplicemente passati in modo diverso quando vengono lanciati.
Le proprietà possono rendere le eccezioni più istruttive rispetto a un messaggio di eccezione che (presumibilmente) è leggibile. Se rilevi un'eccezione, puoi ricevere informazioni sul problema e probabilmente correggerlo automaticamente.
La classe java.sql.SQLException ha String SQLState e vendorCode proprietà, anche con semplici getter.
Mi piace citare Bill Venners che dice: "Lancia le eccezioni ai programmatori, non al codice". Penso che sia una buona regola empirica.
Perché non concatenare tutte le informazioni nella stringa descrittiva dell'eccezione? Il costo della concatenazione di stringhe non verrà eseguito a meno che non venga lanciata un'eccezione. Non farai nulla con quelle informazioni, ma stampalo comunque. Sei?
A meno che tu non voglia in realtà che il tuo programma reagisca all'eccezione in qualche modo. In tal caso, tornerei a Bill Venners "Or" classe . Lo ha presentato nel suo talk Gestione errori funzionali . Contiene un oggetto (proprio come Opzionale o Forse) che può essere un valore Good<T> o un valore Bad<U> . Un Java O è disponibile come bene.
Solo perché puoi fare di più con le eccezioni non significa che dovrebbe . I programmatori funzionali li eliminano del tutto perché sono un effetto collaterale e una fuga dal codice che è difficile ragionare.
Leggi altre domande sui tag java exceptions