Il suffisso Eccezione per le eccezioni in Java

Specificare un suffisso di eccezione sulle classi di eccezioni mi sembra un odore di codice (informazioni ridondanti: il resto del nome implica uno stato di errore ed eredita dall'eccezione). Tuttavia, sembra anche che tutti lo facciano e sembra essere una buona pratica.

Sto cercando di capire perché questa è una buona pratica.

Ho già visto e letto la domanda perché le eccezioni di solito hanno l'eccezione suffisso nel nome della classe

La domanda è per PHP e mentre le risposte sono probabilmente valide per Java. Ci sono altri argomenti o è davvero così semplice come differenziarli esplicitamente?

Se prendiamo gli esempi dalla domanda precedente, potrebbero esserci davvero delle classi in Java con il nome FileNoFoundche non fa eccezione? Se ci può essere, giustifica il suffisso con Exception?

Guardando una rapida gerarchia in eclissi di Exception, abbastanza sicuro, la stragrande maggioranza di loro ha il suffisso di eccezione, ma ci sono alcune eccezioni. javassistè un esempio di libreria che sembra avere alcune eccezioni senza il suffisso - ad esempio BadByteCode, BadHttpRequestecc.

BouncyCastle è un'altra lib con eccezioni come CompileError

Ho cercato su Google un po 'anche con poche informazioni sull'argomento.

java naming exceptions

— drone.ah
fonte

"Tutte le eccezioni dovrebbero contenere un Exceptionsuffisso o dovremmo fare eccezioni per eccezioni eccezionali?" ;)

— martedì

in realtà l'errore è come un'eccezione (vedi OutOfMemoryError) ma sono pensati per cose che sono difficili da recuperare (quindi non le affronti quasi mai)

— maniaco del cricchetto

Inoltre, ho sentito che come regola generale "le classi dovrebbero essere sostantivi e i metodi dovrebbero essere verbi (azioni)". FileNotFound ArrayIndexOutOfBoundse OutOfMemorysono più osservazioni / descrizioni, ma vengono quindi applicate al nome Exception.

— MikeTheLiar,

Risposte:

La risposta di Landei è buona, ma c'è anche la risposta grammaticale. I nomi delle classi dovrebbero essere nomi . Che cos'è un "OutOfMemory"? Che cos'è un "FileNotFound"? Se pensi a "eccezione" come al nome, il descrittore è l'aggettivo che lo specifica. Non è uno qualsiasi Exception, è un FileNotFoundException. Non dovresti aver bisogno di prenderne uno OutOfMemorypiù di quanto andresti al negozio per comprare un "blu".

Questo si presenta anche se leggi il tuo codice come una frase: " Trydoing ..., and catch OutOfMemory Exceptions"

— Bobson
fonte

Per citare l'articolo "Prova a usare nomi perché una classe normalmente rappresenta qualcosa nel mondo reale". Ma le eccezioni rientrano in questo caso? Per me, sono più come un manufatto di programmazione, che rappresenta un messaggio di errore. "Otterrai OutOfMemoryun'eccezione" recita meglio di "Otterrai OutOfMemoryExceptionun'eccezione", vero?

— Gregreg

@ greg0ire - Dovresti provarlo come "Avrai un OutOfMemoryException." Detto questo, abbiamo anche numeri PIN e bancomat, quindi un'eccezione OOME non sarebbe così insolita.

— Bobson,

Penso che il punto che stai facendo qui sia davvero il migliore (quello sui conflitti di nomi non vale più grazie agli spazi dei nomi, almeno in php). Ho più cose da dire su tutto questo e pubblicherò presto una risposta.

— greg0ire,

Fatto! Cosa pensi?

— Gregreg

@Bobson mi raccomando di leggere The Kingdom of Nouns . Non abbiamo bisogno di tutto per essere un nome. Perché "si otterrà un OutOfMemoryException" quando si può semplicemente essere "tu sei la memoria"? Non usiamo Classsuffissi ( DogClass, CatClass, XmlReaderClass, ...).

— Matthieu Napoli,

Penso che le eccezioni (e gli errori, e teoricamente altre Throwable) siano diverse da cose come interfacce o enumerazioni (che di solito non sono usate come suffisso): di solito hanno uno scopo molto chiaro e limitato, sono usate con costrutti linguistici specializzati ( try, catch, throw, throws) e seguire le regole speciali (ad esempio controllato vs eccezioni unchecked, non generici). In un certo senso non sono solo le classi che vengono utilizzate come eccezioni, ma un meccanismo di eccezione che viene implementato mediante le classi.

Quindi, se hai a che fare con un'eccezione e non la riconosci come tale, di solito qualcosa è profondamente sbagliato (che non è ancora il caso di cose come enumerazioni o interfacce). Quindi penso che queste differenze rispetto alle classi "normali" siano abbastanza grandi da richiedere un indizio visivo.

— Landei
fonte

Mi sembra contraddittorio. Se le eccezioni sono speciali e utilizzate in modi speciali e quindi ovviamente riconoscibili, perché hai bisogno di un indizio visivo per?

— Michael Borgwardt,

@MichaelBorgwardt - Penso che stia dicendo che, poiché sono speciali e usati in modi speciali, dovrebbero avere l'indizio visivo per essere ovviamente riconoscibili. Detto questo, non so se è ancora possibile buttare qualcosa che non è ereditato da Exceptionin Java - non è possibile in C #. Se non ci riesci, non riesco a pensare a uno scenario in cui "dovresti affrontare un'eccezione e [non] riconoscerla come tale".

— Bobson,

Non puoi nemmeno lanciare non- Throwables in Java. Tuttavia, è possibile gestire l'eccezione non solo nelle impostazioni try- catch, ad esempio, è possibile raccogliere eccezioni quando si esegue una sorta di convalida per oggetti complessi (quando si desidera conoscere tutti i problemi correlati, non solo il primo). In questi casi dovresti essere consapevole del fatto che puoi, ad esempio, ri-lanciare le cose che hai nella tua lista, quindi sarebbe male chiamarle, ValidationIssueinvece di ValidationException.

— Landei,

Tuttavia, sembra anche che tutti lo facciano e sembra essere una buona pratica.

Sì, tutti lo fanno davvero, quindi è una pratica, ma è ancora buona? Diverse persone si chiedono che:

http://mnapoli.fr/approaching-coding-style-rationally/ (Il suffisso di eccezione § contesto: php)
il video collegato, https://vimeo.com/album/2661665/video/74316116 (salta alle 53:00, contesto: php), ispira l'articolo e sottolinea che ogni volta che usi un'eccezione, hai una parola chiave che mostra già che è un'eccezione nelle vicinanze
http://verraes.net/2013/10/verbs-in-class-names/ mostra come l'affermazione nella risposta di @Bobson potrebbe non essere assoluta, e sottolinea che a volte il suffisso è buono, per l'applicazione o eccezioni a livello di infrastruttura, e talvolta dovresti provare a salvare i personaggi presi da questo lungo suffisso per esprimere qualcosa di più preciso e significativo. Questo punto ha senso solo se si utilizza una lingua in cui la cultura deve utilizzare le eccezioni per le violazioni delle regole aziendali.
il link SO fornito fornisce punti sui conflitti di nomi, ma ora abbiamo spazi dei nomi, no?

— greg0ire
fonte

Questa è una domanda java , non php . I modi di dire sono diversi tra le lingue. Detto questo, ho fortemente in disaccordo con questa citazione dal terzo anello: "Le eccezioni possono essere simili agli eventi, ... con la sfumatura che si tratta di un evento indesiderato, un avvertimento che qualche operazione era incompatibile con, per esempio, le regole di business che sono in vigore ". Forse PHP è diverso al riguardo, ma a mio avviso, le eccezioni dovrebbero essere eccezionali. Se una regola aziendale viene violata in qualsiasi modo previsto, la tua normale logica dovrebbe gestirla, non è un'eccezione al comportamento normale.

— Bobson,

Potresti avere ragione nel dire che varia in base alla lingua per lingua: vedi questa discussione su python: gossamer-threads.com/lists/python/python/796627 . php e python non sono chiaramente incentrati sulle prestazioni, questo forse perché c'è questa differenza con java (che è incentrato sulle prestazioni, giusto?). Se hai diversi livelli da attraversare nel tuo stack di chiamate prima di essere al livello giusto per gestire correttamente la violazione delle regole di business, le eccezioni sono la migliore IMO. Rende anche i tipi restituiti più coerenti (restituisci sempre lo stesso tipo, non falso o vero).

— Modificherò la