L'uso della clausola finally per fare un lavoro dopo il ritorno è cattivo / pericoloso?

Durante la scrittura di un iteratore, mi sono trovato a scrivere il seguente pezzo di codice (eliminazione della gestione degli errori)

public T next() {
  try {
    return next;
  } finally {
    next = fetcher.fetchNext(next);
  }
}

trovandolo leggermente più facile da leggere rispetto a

public T next() {
  T tmp = next;
  next = fetcher.fetchNext(next);
  return tmp;
}

So che è un semplice esempio, in cui la differenza nella leggibilità potrebbe non essere così schiacciante, ma sono interessato all'opinione generale sul fatto che sia male usare try-finally in casi come questo in cui non ci sono eccezioni, oppure se è effettivamente preferito quando semplifica il codice.

Se è male: perché? Stile, prestazioni, insidie, ...?

Conclusione Grazie a tutte le vostre risposte! Immagino che la conclusione (almeno per me) sia che il primo esempio avrebbe potuto essere più leggibile se fosse un modello comune, ma non lo è. Pertanto, la confusione introdotta usando un costrutto al di fuori del suo scopo, insieme a un flusso di eccezioni forse offuscato, supererà qualsiasi semplificazione.

Personalmente, avrei pensato all'idea della separazione delle query dei comandi . Quando si arriva fino ad esso, next () ha due scopi: lo scopo pubblicizzato di recuperare l'elemento successivo e l'effetto collaterale nascosto di mutare lo stato interno di next. Quindi, quello che stai facendo è eseguire lo scopo pubblicizzato nel corpo del metodo e quindi affrontare un effetto collaterale nascosto in una clausola finally, che sembra ... imbarazzante, sebbene non "errata", esattamente.

Ciò che si riduce davvero è quanto sia comprensibile il codice, direi, e in questo caso la risposta è "meh". Stai "provando" una semplice dichiarazione di ritorno e quindi eseguendo un effetto collaterale nascosto in un blocco di codice che dovrebbe essere per il recupero degli errori a prova di errore. Quello che stai facendo è 'intelligente', e il codice 'intelligente' spesso induce i manutentori a borbottare, "che cosa ... oh, penso di averlo capito." Meglio che le persone che leggono il tuo codice borbottino "sì, uh-huh, ha senso, sì ..."

Quindi, cosa succede se si separa la mutazione di stato dalle chiamate degli accessor? Immagino che il problema della leggibilità di cui ti occupi diventa discutibile, ma non so come questo influisca sulla tua più ampia astrazione. Qualcosa da considerare, comunque.

Puramente dal punto di vista dello stile, penso a queste tre linee:

T current = next;
next = fetcher.getNext();
return current;

... sono entrambi più evidenti e più brevi di un blocco try / finally. Dato che non ti aspetti che vengano generate eccezioni, l'uso di un tryblocco confonderà le persone.

Ciò dipende dallo scopo del codice all'interno del blocco finally. L'esempio canonico sta chiudendo un flusso dopo aver letto / scritto da esso, una sorta di "pulizia" che deve essere sempre fatta. Ripristinare un oggetto (in questo caso un iteratore) su uno stato valido IMHO conta anche come cleanup, quindi non vedo alcun problema qui. Se OTOH stavi usando returnnon appena è stato trovato il tuo valore di ritorno e aggiungendo un sacco di codice non correlato nel blocco finally, allora oscurerebbe lo scopo e renderebbe tutto meno comprensibile.

Non vedo alcun problema nell'usarlo quando "non ci sono eccezioni". È molto comune usare try...finallysenza un catchquando il codice può solo essere lanciato RuntimeExceptione non hai intenzione di gestirli. A volte, finalmente è solo una salvaguardia, e sai per la logica del tuo programma che non verrà mai generata alcuna eccezione (la classica condizione "questo non dovrebbe mai accadere").

Insidie: qualsiasi eccezione sollevata all'interno del tryblocco farà finallycorrere il bock. Questo può metterti in uno stato incoerente. Quindi, se la tua dichiarazione di ritorno fosse simile a:

return preProcess(next);

e questo codice ha sollevato un'eccezione, fetchNextverrebbe comunque eseguito. OTOH se lo hai codificato come:

T ret = preProcess(next);
next = fetcher.fetchNext(next);
return ret;

quindi non funzionerebbe. So che stai assumendo che il codice di prova non possa mai sollevare alcuna eccezione, ma per casi più complessi di questo come puoi esserne sicuro? Se il tuo iteratore fosse un oggetto di lunga durata, continuerebbe a esistere anche se si verificasse un errore irreversibile nel thread corrente, quindi sarebbe importante mantenerlo in uno stato valido in ogni momento. Altrimenti, non importa molto ...

Prestazioni: sarebbe interessante decompilare tale codice per vedere come funziona sotto il cofano, ma non conosco abbastanza della JVM per nemmeno fare una buona ipotesi ... Le eccezioni sono di solito "eccezionali", quindi il codice che gestisce non hanno bisogno di essere ottimizzati per la velocità (da qui il consiglio di non usare mai le eccezioni nel normale flusso di controllo dei tuoi programmi), ma non lo so finally.

La frase del titolo: "... finalmente la clausola per fare un lavoro dopo il ritorno ..." è falsa. Il blocco finally si verifica prima che la funzione ritorni. Questo è il punto finale di fatto.

Quello che stai abusando qui è l'ordine di valutazione, in cui il valore di next viene memorizzato per essere restituito prima di modificarlo. Non è una pratica comune e secondo me sbagliata in quanto ti rende il codice non sequenziale e quindi molto più difficile da seguire.

L'uso previsto dei blocchi finally è per la gestione delle eccezioni in cui devono verificarsi alcune conseguenze indipendentemente dalle eccezioni generate, ad esempio pulizia di alcune risorse, chiusura della connessione DB, chiusura di un file / socket ecc.

Starei molto attento, perché (in generale, non nel tuo esempio) una parte in try può generare un'eccezione, e se viene espulso, nulla verrà restituito e se in realtà hai intenzione di eseguire ciò che è finalmente dopo il ritorno, lo farà esegui quando non lo volevi.

E un'altra lattina di worm è che, in generale, qualche utile azione alla fine può generare eccezioni, quindi puoi finire con un metodo davvero disordinato.

Per questo motivo, qualcuno che lo legge deve pensare a questi problemi, quindi è più difficile da capire.