Devo usare un'eccezione in un caso come questo? [duplicare]

Question

Devo usare un'eccezione in un caso come questo? [duplicare]

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

0

Ho un servizio di Windows con un'interfaccia fluente come questa:

aRequest = Repository.getRequest()
                     .createProcess()
                     .validate();

A volte getRequest() potrebbe restituire un valore null e ciò causerebbe un errore in createProcess() . Potrei dividere banalmente getRequest() da createProcess() , ma se non lo farei in che modo dovrei seguire, quale è il modo migliore:

Verifica se la richiesta ( this ) è nullo e nel caso restituisce null:
```
if(this is null)
  return null
```
Potrei fare questo controllo in tutti i metodi accanto a getRequest() . Alla fine aRequest sarà null .
Genera un'eccezione se il metodo createProcess() riceve un valore null :
```
if(this is null)
   throw new NullRequestException();
```

PRO del secondo modo: solo il secondo metodo richiede un controllo, indipendentemente dal numero di metodi nella catena.

CON del primo modo: ogni metodo nella catena ha bisogno di un controllo

Ora la domanda: la seconda è un cattivo uso del concetto di eccezione, poiché potrebbe essere normale l'assenza di richiesta a volte?

design exceptions

posta BAD_SEED 30.04.2014 - 17:01

fonte

3 risposte

Leggi altre domande sui tag design exceptions

Order of Operations Annoyance [duplicato] Agisci come server MySQL in Java / Android [chiuso]

score 2 · Answer 1

Se vuoi mantenere la sintassi fluente, getRequest() non deve mai restituire null! L'interfaccia fluente deve restituire this ad ogni passaggio e this non può essere nullo. ;)

Se la chiamata interna all'interno di getRequest restituisce un valore null, è necessario modificare lo stato del repository in modo che validate() possa rilevare tale condizione e generare un'eccezione o gestirla in modo appropriato. Potresti avere una variabile membro "String answer;" e imposta & controlla quello per null, o hai un "booleano nullAnswer;" membro.

Inoltre, dai un'occhiata alla classe "Opzionale" di Guava, perché è un ottimo modo per gestire i valori che potrebbero non essere presenti. Anche allora, assicurati che i tuoi metodi fluenti sempre restituiscano this (o la variante return new Respository(...) ).

score 1 · Answer 2

È possibile non restituire null da getRequest() , o almeno avere una versione separata di esso? Se invece lanciasse un'eccezione e le altre parti della catena farebbero lo stesso, avresti una buona gestione degli errori coerente.

Peccato che sia Java che C # non abbiano gli idiomi Maybe e Either ; Optional ha visto qualche adozione, però. Restituire null è una cattiva idea: nasconde la fonte del tuo problema. È esasperante durante la risoluzione dei problemi. In generale, fallire velocemente, proprio dove si verifica il problema. Userei le eccezioni.

score 0 · Answer 3

Penso che sia corretto che getRequest restituisca null , purché il lettore sappia che può farlo.

Il problema del tuo esempio, nel modo in cui è scritto, si legge come dovrebbe al 100% del tempo in cui creerà un processo.

Se l'aspettativa è che getRequest non debba mai restituire null, allora quel metodo dovrebbe essere quello che lancia l'eccezione. Se è previsto che getRequest restituisca null, è necessario modificarne l'utilizzo per gestirlo.

private Request createProcessIfRequestFound() {
    var request = Repository.getRequest();

    if (request != null) {
        request.createProcess().validate(); 
    }

    return request;
}

La mia preferenza personale è quella di evitare interfacce fluide, a mio avviso, ironicamente, trovo che siano meno fluenti di scrivere codice non "fluente"