Quindi, stavo pensando di scrivere eccezioni personalizzate oggi e ho considerato l'eccezione dell'operazione non valida. Questa eccezione può significare molte molte cose e, in alcune azioni, le operazioni potrebbero non essere valide a causa di più cause indipendenti. Considera questo esempio. (E sì, so che una ArgumentException sarebbe meglio qui, ma sto cercando di trovare un semplice esempio di eccezione di un'operazione non valida)
public GetLocationFromLatLong(float Lat, float Long){
if ( Lat < -90 || Lat > 90){
throw new InvalidOperationException("Latitude is out of bounds")
}
if ( Long < -180 || Long > 180){
throw new InvalidOperationException("Longitude is out of bounds")
}
/*Actual function here*/
}
Se volessi gestire l'eccezione di cui sopra, avrei bisogno di ispezionare il messaggio per vedere quale argomento era fuori intervallo, e poi chiedere all'utente. Anche se questo non è esattamente BAD, il metodo potrebbe alternativamente lanciare eccezioni come "InvalidLatitude" e "InvalidLongitude" (entrambe erediterebbero da System.InvalidOperationException ed essere funzionalmente identiche), e potrei prendere uno di questi individualmente e agire da quello. La domanda è, queste eccezioni sarebbero strutturalmente diverse da System.InvalidOperationException, quindi aggiungerei un altro livello di astrazione al codice che potrebbe non essere necessario.
Credo che questo potrebbe rendere il codice più leggibile in alcuni casi, ma allo stesso tempo ho sentito spesso che "Less is more" in termini di codifica. È un odore di codice, o c'è un motivo per non farlo?