La risposta è ovviamente "dipende", ma dato il tuo caso d'uso, direi di no. Ecco perché:
C # è un meraviglioso graffio che è il miglior linguaggio orientato agli oggetti. È così bello, infatti, che a volte mi ritroverò a cercare di attuare una visione fanaticamente purista di ciò che è iniziato come un semplice progetto. Questo non mi succede così tanto quando scrivi codice JavaScript o Objective-C o PHP.
Quando arrivo in questa "modalità", questo tipo di paralisi, uno dei sintomi può essere un'ossessione per la gestione delle eccezioni, i generici e la meta-programmazione. A volte tutti e tre insieme. È molto più probabile che si tratti di un problema quando sto lavorando a qualcosa di nuovo, relativamente sconosciuto o con specifiche e obiettivi scadenti. Piuttosto che impantanarmi nei dettagli di implementazione , penso, perché provare a creare qualcosa che possa ospitare la maggior parte degli scenari che ragionevolmente prevedo? Poi, quando avrò modo di ottenere i dettagli, le basi saranno poste e scriverò un mucchio di piccoli e tozzi metodi, e così via. Forse qualcun altro funzionerà sul codice dell'interfaccia utente, fornirò loro solo questi servizi e questi contratti ...
Purtroppo, questo deve ancora capitare a me. Quello che tende ad accadere è che ho iniziato questo percorso lavorando su "infrastruttura" - cose come:
- Scrittura delle mie interfacce contenitore IoC o altrimenti avvitamento con
Castle.Windsor
- Determinare come gestirò il mapping dei tipi nell'applicazione
- Scrittura della logica del flusso di controllo per le classi di base astratte che assomigliano a
Interceptors e che racchiudono le chiamate ai membri astratti con la gestione delle eccezioni
- Creazione di classi base astratte per
IRepository , IUnitOfWork , IDomainService , ICrossCuttingValidation , ecc.
- Cercando di descrivere un modello di oggetto gerarchico per qualcosa la cui stessa natura nega un tale approccio meta- ( come
IFrameworkException )
Quando rimani impiccato sul fatto che la descrizione di un'eccezione sia abbastanza precisa per i tuoi gusti, stai davvero negando l'implementazione di alcune altre funzionalità critiche. La natura dell'eccezione è anche indicativa - non è un'eccezione event -driven, si verifica evidentemente lontana da qualsiasi metodologia di input (come un'interfaccia utente o una pipe o qualcosa del genere) ed è probabilmente deterministica in natura - come in, non puoi prevedere cosa verrà inserito da un utente, ma puoi prevedere quale assembly scegli di caricare o whatnot.
A proposito, se la descrizione ti disturba tanto, non puoi scrivere un metodo di estensione per sovrascriverlo nell'ambito appropriato?
Quindi questo è solo il mio modo di proiettare su di te la mia paralisi di astrazione e astrazione, ma penso che potrebbe essere appropriato. Direi che per rimanere al sicuro, solo sottoclasse un Exception quando:
- Hai effettivamente riscontrato un'eccezione di runtime che stai cercando di gestire in generale
- L'eccezione di runtime non è qualcosa che potresti ragionevolmente escludere in fase di progettazione
- L'eccezione non è già ben coperta dall'enorme numero esistente di
Exception sottoclassi
- In realtà hai un'idea di come vuoi gestire l'eccezione O se no, solo perché è così complicato che devi pensarci e tornare ad esso
- La tua idea va oltre la modifica dei suoi metadati, il suo ambito, la sua eccezione interna, ecc. e tratta di più con l'oggetto o l'evento sottostante che produce l'eccezione e / o i mezzi per gestirlo effettivamente
- Hai già scritto o non sei responsabile per la maggior parte del lato di input delle cose come l'interfaccia utente