Ho un caso in cui vorrei evitare di utilizzare le eccezioni per gli errori di convalida nel parametro di callback della mia funzione. Questi errori non sono davvero eccezionali e try...catch può impedire a un motore JS di ottimizzare l'intera funzione (che fa importa in tutti i progetti con cui lavoro). Il callback è pensato per essere implementato dai miei utenti della biblioteca. Mi sembra che l'unico modo corretto per gestirlo sia
- restituire un oggetto come
{type: 'error', value: '...some error description...'}e{type: 'success', value: 123}... - ... o allo stesso modo, ma sviluppato ulteriormente: crea un tipo di dati algebrico
Result = Ok(value) | Err(error)e restituisce la sua istanza.
Quest'ultimo approccio è molto pulito e conveniente, porta a un codice migliore rispetto alle eccezioni e consente molti metodi utili (ad esempio la funzione map che trasforma Ok e ignora Err , rileva automaticamente un'eccezione e la converte in Err , ecc.). Questo approccio è ampiamente utilizzato in Haskell e Ruggine .
Il problema è che non ho mai visto questo approccio utilizzato nel codice di produzione JavaScript, quindi non sarà familiare alla maggior parte degli sviluppatori che lavorano con i miei progetti. Inoltre, l'introduzione di un modo così pratico di lavorare con errori mi motiva a usarlo su tutto il codice base, sostituendo con esso le eccezioni native ed esponendo i valori di Result nelle interfacce pubbliche. Altrimenti la gestione degli errori diventa incoerente.
Quindi, è una buona idea usare un concetto che sostituisce la gestione delle eccezioni native? Ci sono aspetti negativi? Probabilmente non è male (abbiamo sostituito i callback con le promesse molto prima che diventassero uno standard), ma non sono sicuro.