In quali scenari gli oggetti 'funzionali' 'Try' sono più o meno vantaggiosi degli oggetti 'rx' 'Try'?

Entrambi sono gestioni degli errori in "stile funzionale". L'unica differenza è che quest'ultimo ti consente di specificare che gestirà alcune eccezioni in stile funzionale lasciando che il resto sia gestito in stile imperativo, mentre il primo gestisce le tutte eccezioni in stile funzionale, costringendo il programmatore a rimuovi manualmente eventuali eccezioni non gestite.

Lo svantaggio principale della gestione delle eccezioni in stile imperativo è che le eccezioni si propagano solo in un modo: dritto nello stack delle chiamate. Hai la possibilità di gestirlo lì nello stack delle chiamate o lasciarlo propagare. Implica anche determinate scelte di scoping variabili su di te. Questa è semantica molto limitante.

Al contrario, Trys sono molto flessibili. Si tratta di oggetti regolari che possono essere archiviati, condivisi, aggregati, concatenati e gestiti in qualsiasi momento, non solo laddove si è verificato lo stack di chiamate quando si è verificato l'errore. Può richiedere un po 'di tempo per vedere l'utilità di questo.

Un esempio recente di lavoro era che avevamo un elenco di server e volevamo trovare il primo con una connessione funzionante. L'API con cui stavamo lavorando ha generato un'eccezione al tentativo di connettersi a un server inattivo. Lo sviluppatore che ha scritto la prima bozza di questo codice ha avuto un sacco di problemi con condizioni al contorno e portata variabile a causa dell'uso di blocchi try-catch e ha chiesto aiuto. Trys ha reso l'attività molto semplice mappando pigramente l'elenco dei server a un elenco di Trys , quindi trovando il primo Success .

Vi incoraggio a dare a queste librerie un provare (gioco di parole) e vedere come possono semplificare la complessa gestione degli errori. Da quando ho imparato circa Trys , non ho ancora visto un caso che non siano stati semplificati.

Sono l'autore del ciclope Prova l'implementazione, quindi potrei essere in grado di far luce sulle decisioni di progettazione che stanno dietro.

Per iniziare, le implementazioni hanno molte somiglianze, in quanto è possibile costruire direttamente i tipi di successo e di fallimento, oppure eseguire un fornitore e scegliere di gestire eventuali eccezioni che potrebbero essere lanciate da esso.

L'obiettivo di Cyclops Try non è quello di incoraggiare un approccio misto di gestione delle eccezioni imperativo e funzionale. Se si utilizza cyclops, provare a utilizzare tutte le funzioni di gestione delle eccezioni. Ma dovrebbe anche essere premeditato.

Per impostazione premeditata, intendo che in fase di progettazione dovresti limitare l'ambito di quali stati eccezionali ti aspetti che il tuo codice possa entrare e configurare Prova a intercettare le relative eccezioni solo .

Il motivo è semplice, qualsiasi tipo di eccezione che non hai pianificato è un bug e in quel caso dovremmo fallire velocemente. Vuoi catturare bug durante le prove unitarie o idealmente nei tuoi ambienti di test. Non in produzione, e non penso che tu voglia mascherarli permanentemente in produzione.

Puoi dire a ciclope Prova a catturare tutte le eccezioni (ad esempio passando a Throwable) e il comportamento sarebbe quindi lo stesso lambdista Try.

Un'altra differenza è che i metodi map e flatMap non gestiscono eccezioni successive per impostazione predefinita. È possibile configurare questo in modo che le successive eccezioni dei tipi specificati creando direttamente un oggetto di successo. Il ragionamento qui era anche quello di accertarsi che qualsiasi gestione delle eccezioni fosse intenzionale e non nascondesse errori (al contrario di incoraggiare gli sviluppatori a utilizzare un blocco Try / Catch altrove - preferiremmo non averlo fatto).