Riusa JSE ha verificato le eccezioni come deselezionate

Question

Riusa JSE ha verificato le eccezioni come deselezionate

#1 da (1 voti)

0

In realtà quello che sto facendo nella mia base di codice è la duplicazione di eccezioni java già controllate come MalformedURLException.class mantenendo lo stesso nome di eccezione mentre ereditate da RuntimeException.class. Sinceramente, non ho trovato un modo migliore.

L'ho trovato davvero pessimo, perché ora ho quasi 8 eccezioni duplicate solo perché, nel mio caso, non posso recuperare da questi tipi di eccezioni e non voglio buttarle da ogni livello finché non raggiungono il livello più alto in quanto renderebbe la manutenibilità del codice un incubo.

Francamente, penso che oracle / sun dovrebbe aver pensato a questo caso di riutilizzabilità e rendere il tipo di eccezioni flessibile e scelto al momento del lancio, qualcosa di simile al seguente invece di affidarsi al genitore dell'eccezione:

throwChecked new MalformedURLException();

Sia IMO RuntimeException.class che Exception.class dovrebbero essere deselezionate e spetta allo sviluppatore scegliere quale sarà il suo lancio.

quindi la mia domanda mi è sfuggita nel mio caso e nelle mie analisi?
esiste un approccio migliore senza duplicare?

Cordiali saluti!

Modifica

Nota anche duplicando queste eccezioni, mi sono trovato obbligato a coprire tutti i rami delle mie classi quindi coprire tutte le eccezioni create anche se voglio avere una buona copertura.

java exceptions

posta isqo 13.11.2018 - 22:50

fonte

1 risposta

Leggi altre domande sui tag java exceptions

Come definire una struttura per memorizzare alcune classi generiche "Variabili" per un facile accesso in seguito Referenziamento entità all'interno di aggregati per ID locale

score 1 · Answer 1

Le eccezioni controllate sono praticamente uniche per Java e mentre possono avere un certo valore, è davvero difficile sapere quando un'eccezione deve essere controllata o meno al momento in cui stai scrivendo un'API. La tua idea è interessante ma a meno che tu non scriva una nuova lingua dovrai occupartene come sono.

La tua motivazione a utilizzare eccezioni non controllate invece dei casi in cui non è possibile ripristinare è completamente valida. Probabilmente non duplicherò i nomi delle classi di eccezioni, comunque. Non c'è nulla di intrinsecamente sbagliato in questo, ma potrebbe essere davvero fonte di confusione per gli altri sviluppatori, specialmente se sono usati in Java. Ad esempio, le tracce dello stack saranno strane se si cattura l'eccezione causa perché il nome dell'eccezione sarà lo stesso (a parte il pacchetto). Inoltre, (penso) dovremo usare i nomi di classe completi in molti posti che può davvero rendere il codice brutto.

Invece quello che tendo a fare è creare un numero di classi RuntimeException che hanno più nomi come ConfigurationException o UnrecoverableExecutionException o qualsiasi cosa abbia senso nell'app. Questi prendono un parametro cause che accetta l'eccezione verificata originale in modo che venga mantenuto lo stacktrace completo. Questo ti dà anche la possibilità di aggiungere più codice di gestione degli errori in queste classi di eccezioni per fare cose come catturare il contesto intorno all'eccezione.