Usa la possibilità di restituire i booleani dopo le chiamate di metodo per un livello facoltativo di gestione delle eccezioni? [duplicare]

Question

Usa la possibilità di restituire i booleani dopo le chiamate di metodo per un livello facoltativo di gestione delle eccezioni? [duplicare]

#1 da (2 voti)

1

Vorrei chiedere un seguito a una domanda che ho appena posto: Meglio hai 2 metodi con un chiaro significato, o solo 1 metodo a doppio uso? Ora capisco perché è meglio separare charge(float c); e getBalance(); .

Tuttavia, ogni metodo ha l'opportunità di restituire un valore. Quindi, forse usa questa opportunità e restituisci solo un boolean che significa che non c'è stato alcun problema con l'esecuzione del metodo?

public class Client {
    private float bal;
    float getBalance() { return bal; }

    boolean charge(float c) {
        if(bal < 0) return false; // some weird, illegal, state
        bal -=c;
        return true;
    }
}

Il ritorno di booleans per successo / fallimento abilita un livello aggiuntivo (facoltativo) per la gestione delle eccezioni.

Voglio dire, se non ti interessa il boolean restituito, ignoralo. Non lo so, penso solo perché non restituire "qualcosa"?

interfaces

posta david 05.02.2016 - 21:19

fonte

1 risposta

Leggi altre domande sui tag interfaces

Quale principio di OOAD sta rompendo questo schema? Esiste una bomba a tempo nell'assegnazione di ID processo sequenziale quando il "non firmato" si avvolge?

score 2 · Answer 1

Sembra che tu stia sostenendo che un valore di ritorno "non utilizzato" è un'occasione sprecata per fornire al chiamante ulteriori informazioni. Vorrei invece discutere:

Fornire un valore di ritorno aggiunge un'altra cosa che gli utenti della tua API devono conoscere e tenere traccia di.
Fornendo un valore di ritorno che il chiamante ha bisogno di per controllare (come nel caso tipico di un successo / fallimento booleano) introduce la possibilità che il chiamante dimentichi di controllare quel valore di ritorno. / p>

Quindi restituire qualcosa piuttosto che niente non è automaticamente vincente. Se sia la cosa giusta da fare dipende da altre considerazioni.

È possibile implementare questo metodo in un modo che rende impossibile fallire? (ignorando radiazioni cosmiche e topi masticando il cablaggio e così via) Quindi non restituire nulla. Agli utenti piace quando le cose non possono fallire.
L'errore è insolito? Quindi considera la possibilità di lanciare un'eccezione. Il dibattito tra eccezioni e valori di ritorno è troppo complicato per entrare qui ( vedi il duplicato proposto da gnat ), quindi mi limiterò a sottolineare che i valori restituiti silenziosamente non riescono a fare nulla se il chiamante non li controlla, mentre le eccezioni sono" impossibili da ignorare " .
È probabile che l'errore indichi un bug nel codice chiamante? Quindi prendi in considerazione asserzioni o eccezioni che forniscono qualche utile messaggio di errore al programmatore che ha commesso l'errore.

In questo caso potresti potenzialmente rispondere sì a tutte e tre le domande. Puoi evitare che bal diventi negativo negli altri tuoi metodi. Probabilmente puoi presumere che la maggior parte dei tuoi clienti avrà un bilancio positivo per la maggior parte del tempo. Puoi sostenere che il chiamante dovrebbe sempre controllare getBalance() prima di charge() . Qui è dove devi fare una chiamata soggettiva.

P.S:.

Returning booleans for success / failure enables an (optional) extra layer for exception handling.

Se la possibilità di fallire è inevitabile, allora sarei d'accordo sul fatto che dovresti fare qualcosa quando si verifica un errore se non ignorarlo silenziosamente. Ma ci sono molti modi per avvisare il chiamante del problema o almeno consentire al chiamante di rilevare il problema, come lanciare le proprie eccezioni, asserire sull'errore, esporre lo stato dell'account tramite un altro metodo, o restituire un enum di vari codici di errore. Restituire un booleano è solo una delle molte opzioni. A volte è l'opzione migliore, ma non sempre.