Perché le eccezioni sono usate per rifiutare le promesse in JS?

La specifica a cui mi riferisco è su http://promises-aplus.github.io/promises-spec/ .

Quando usi then() , puoi o restituire una promise e respingere la promise quando desideri, oppure puoi lanciare un’eccezione per rifiutare una promise.

Perché l’API non è stata concepita in modo tale per cui, per la funzione then , è stata approvata una funzione di risoluzione e rifiuto come il costruttore della promise originale?

Le eccezioni sono pesanti in molte lingue (e presumo anche in javascript), quindi sembra strano che le stiano utilizzando come scelta per il controllo del stream. Creare un object promise completamente nuovo e restituirlo, solo per respingerlo, aggiunge al codice bloat IMO. Il debug diventa anche più difficile nel caso in cui venga lanciata un’eccezione (come errori di syntax, o se la funzione viene chiamata su un object non definito, ecc.)

Perché l’API non è stata concepita in modo tale per cui, per la funzione allora, è stata approvata una funzione di risoluzione e rifiuto come il costruttore della promise originale?

In realtà, l’API in quella specifica è emersa come un consenso tra varie implementazioni. Tuttavia, alcuni punti che potrebbero aver portato a questo sono:

  • then è un metodo piuttosto funzionale. Il callback deve ricevere solo un argomento di dati, il valore risultante della promise.
  • Passare ulteriori funzioni di resolve / reject al callback non funziona bene con più argomenti o persino funzioni variadiche.
  • then solito viene usato come una funzione di mapping semplice. È sufficiente return il nuovo valore, non è necessaria alcuna resolve .
  • Quando vuoi veramente fare qualcosa di asincrono nella tua richiamata in cui puoi usare resolve / reject , è meglio usare comunque una promise, che puoi semplicemente restituire.

Una volta ho implementato un lib di Promise con argomenti di resolve / reject opzionali, ma era noioso da usare – e raramente avevo bisogno di loro a causa del # 4. Usarli era sobject a errori, si poteva facilmente dimenticare qualcosa (come errori di gestione o eventi di avanzamento), proprio come le persone che costruiscono manualmente e restituiscono i differenziali che vengono risolti dai promessi callback, invece di chiamare in then .

Le eccezioni sono pesanti, quindi sembra strano che le utilizzino come scelta per il controllo del stream.

Non sono pensati per essere utilizzati per il controllo del stream (come ramificazioni, loop, ecc.) Ma per la gestione delle eccezioni : i rifiuti sono eccezionali . La maggior parte degli sviluppatori Promise ha voluto implementarli come alternativa per il codice sincrono (bloccante), in cui l’IO generava sempre eccezioni, quindi l’hanno adattato. I rigetti sono ancora spiegati come l’equivalente asincrono di try … catch , anche se la loro natura monadica potrebbe essere utilizzata in modi più potenti e applicazioni di livello superiore.

Creare un object promise completamente nuovo e restituirlo, solo per respingerlo, aggiunge al codice bloat IMO.

Non c’è molta differenza tra return new RejectedPromise(…) , return reject(…) e throw Error(…) .

Il debug diventa anche più difficile nel caso in cui venga lanciata un’eccezione (come errori di syntax, o se la funzione viene chiamata su un object non definito, ecc.)

La maggior parte degli sviluppatori di Promise sembra vederlo come un vantaggio in realtà – le eccezioni (inaspettate) anche nel codice asincrono verranno catturate automaticamente, in modo che possano essere gestite invece di far saltare il programma (inosservato). Vedi anche la gestione delle eccezioni, gli errori lanciati, le promesse e il modello di promise accettabile per gli errori “LOUD”? .