Qual è il vantaggio del wrapping delle eccezioni [duplicato]

per nascondere quale fosse la causa principale nei luoghi in cui non ha importanza

il livello principale deve solo sapere che si è verificata un'eccezione di archiviazione invece di una SQLException, che potrebbe non verificarsi se si decide di migrare a un archivio dati non SQL

non l'involucro perde anche l'astrazione e richiede la reimplementazione del livello superiore quando si esegue una migrazione di un livello inferiore che utilizzerà quindi eccezioni diverse

Un principio convincente alla base della gestione degli errori consiste nel gestire l'errore nel livello più adatto per gestire l'errore. Gestire un errore può comportare il riprovare dell'operazione, segnalare l'utente o semplicemente capovolgersi e morire.

Spesso, questo significa che la gestione degli errori è curata abbastanza in alto nello stack dell'applicazione poiché non si desidera che il codice di gestione degli errori duplicato sia sparso in tutta l'applicazione. Allo stesso modo, gli strati inferiori non avranno le informazioni necessarie per capire quale tipo di azione correttiva è appropriata.

Ma questo presenta un problema quando la gestione degli errori è abbastanza alta nello stack e l'errore si verifica in un punto piuttosto basso nello stack. Quello che chiami "dati marginalmente più contestuali" sono informazioni che il livello più basso fornisce al livello di chiamata per dare al livello di chiamata una soluzione migliore per intraprendere azioni correttive invece di ribaltare e morire.

Nel tuo caso specifico, sembra che tu abbia bisogno di un'ulteriore gestione degli errori più vicina alla chiamata al database, in modo che tu possa intraprendere azioni correttive più appropriate.