Progettazione della libreria Scala che avvolge una libreria Java

Question

Progettazione della libreria Scala che avvolge una libreria Java

#1 da (1 voti)
#2 da (1 voti)

1

Sto progettando una semplice libreria di scala scala su una libreria java per renderla più idiomatica scala. Il problema che ho dovuto affrontare è che tutte le operazioni dalla libreria java possono generare un'eccezione, che è RuntimeException , ma molto simile a IOException . Quindi mi chiedo se sia una buona idea avvolgerli tutti in Either o dovrei lasciarlo a un utente della mia libreria? Credo che dovrei lasciarlo a un utente, ma mi piacerebbe esserne sicuro, ho ragione.

api-design scala

posta alex 14.02.2017 - 14:17

fonte

2 risposte

1

Dipende dal tuo pubblico di destinazione. Se si punta al lato FP della comunità di Scala, le eccezioni per qualsiasi cosa tranne i guasti critici sono inaccettabili - fanno per codice non sicuro. Comprenderei errori in Either o almeno a Try . Preferibilmente un Either , poiché non eseguono il failover su eccezioni e sono corretti correttamente nelle versioni recenti.

Se stai mirando al lato più intermedio / OOP della comunità di Scala, le eccezioni vanno bene, questo è quello che ci si aspetta di solito.

risposta data 14.02.2017 - 18:48

fonte

Leggi altre domande sui tag api-design scala

Iniezione di dipendenza qualificata e accoppiamento Separa il livello di presentazione dalle entità di dati

score 1 · Accepted Answer

Se l'evento è molto raro, lo lascerei propagare. Se è relativamente comune, preferirei effettivamente un Future . Sono già progettati per contenere eccezioni e molte attività che falliscono spesso tendono anche a trarre vantaggio dall'esecuzione asincrona, come le query di I / O di rete. È abbastanza comune vedere API piene di funzioni che restituiscono Futures , mentre non ne ho mai visto uno che faccia un uso pesante di Eithers .