Richiami diversi per errore o errore come primo argomento?

Question

Richiami diversi per errore o errore come primo argomento?

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)

12

Noi (e la chat room di JS SO) abbiamo parlato con @rlemon qualche giorno fa del suo Little-XHR libreria sulla gestione degli errori.

Fondamentalmente, volevamo decidere quale modello di gestione degli errori dovrebbe essere usato:

xhr.get({
    // Some parameters, and then
    success: function(data) {},
    failure: function(data) {}
})

o

xhr.get({
    // Some parameters, and then
    callback: function(err, data) {}
})

Uno è più simile a jQuery, mentre l'altro è più simile a Node. Alcuni dicono che il primo modello ti fa pensare di più sull'errore di gestione. Penso al contrario, dato che potresti dimenticare l'altra funzione di callback, mentre l'argomento è sempre lì sul secondo pattern.

Qualche opinione / vantaggio / svantaggio su entrambi questi modelli?

error-handling javascript

posta Florian Margaine 12.04.2012 - 12:35

fonte

3 risposte

Leggi altre domande sui tag error-handling javascript

Cosa dovrebbe essere testato in Javascript? Flusso di lavoro GIT per lo sviluppo web

score 5 · Answer 1

La vera caratteristica importante è la coerenza dello stile, in modo che tu possa scrivere codice nello stesso stile e puoi fare supposizioni sulla meta programmazione su come vengono gestite le situazioni asincrone.

Personalmente preferisco

(err, data) perché è un modo standard di gestire le cose. Permette la composizione delle funzioni.

Ad esempio after.map utilizza questo modello. Così codice come

after.map(["foo.js", "bar.js"], function (fileName, callback) {
    fs.readFile(fileName, function (err, file) {
        callback(err, file)
    })
}, function (err, files) {
    // handle files
})

può essere semplificato in

after.map(["foo.js", "bar.js", fs.readFile, function (err, files) {
    // handle files
})

Un altro vantaggio è che puoi passare in un callback come ultimo parametro

asyncOperation(options, function (err, data) {
    // not nested inside an object literal
})

L'ultimo approccio al callback è un buon approccio all'usanza delle API.

Un ulteriore vantaggio è che puoi facilmente dimenticarti di impostare il error handler nel tuo oggetto letterale o di impostarlo su un tipo di gestore degli errori predefinito.

Quando usi (err, data) ti ricorda di pensare a come gestire in modo efficiente questo errore ogni volta.

score 2 · Answer 2

In generale, mi piace ricordare che esplicito è sempre meglio di implicito.

Usando questo, di solito utilizzerei le funzioni success e failure esplicite: sai esattamente cosa hai a che fare nel momento in cui apri quel codice - le chiamate di successo che hanno avuto esito positivo, mentre l'errore si occupa di chiama che ha avuto un problema.

L'alternativa, utilizzando un singolo metodo, richiederà più tempo per leggere quando si modifica questo codice. Inoltre, probabilmente ti ritroverai con qualcosa del genere;

xhr.get({
    callback: function(err, data) {
        if (err) {
            // handle that error somehow
        }
        else {
            // deal with success somehow
        }
    }
})

E quel tipo di placca diventa noioso, veloce.

Per non parlare del fatto che, se si dimentica di aggiungere questo standard, e per esempio, si sta solo gestendo il successo, allora un nuovo sviluppatore che sta inserendo il codice base potrebbe non vedere un problema con esso. Ma avendo espliciti richiami di errore / successo, sarebbero in grado di vedere abbastanza rapidamente che ti manca un callback error e iniziare a lavorare su un modo per gestirlo, o almeno a capire "bene, questo è solo gestire il successo - Devo trovare un modo per gestire gli errori ". Rende il codice meno magico.

score 1 · Answer 3

Separa i callback

Se la chiamata xhr.get() ha esito positivo, allora err è ridondante. Se la chiamata fallisce. data è ridondante. Piuttosto che forzare il codice client a controllare lo stato di uno o dell'altro, non passare entrambi.

Se risulta che il successo potrebbe rappresentare un successo parziale, indicarlo separatamente. Il fallimento è solitamente l'opzione di salvataggio.

Ho lavorato con sviluppatori che gestiscono solo il caso di successo e in molti scenari l'implementazione di una callback di successo sarebbe sufficiente in questo caso. Un callback multi-stato sarebbe un'opzione catastrofica per quello stile di programmazione in quanto assumerebbe il successo.