Best practice per il valore di ritorno del servizio angolare

Question

Best practice per il valore di ritorno del servizio angolare

#1 da (2 voti)

3

Ho una serie di servizi angolari (ad esempio un servizio utente) che effettuano varie chiamate HTTP e mi chiedo quale sarebbe la migliore pratica per gestire gli errori. Ad esempio, potrei fare:

function getAll(success, error) {
    $http.get('/api/users').then(success, error);
}

O potrei fare:

function getAll(success) {
    $http.get('/api/users').then(success, function(err) {
        success([]);
    });
}

Il vantaggio del primo è che è più configurabile nel caso volessi fare qualcosa di speciale. Tuttavia, il vantaggio del secondo è che mantiene i controllori più semplici e nel caso (si spera raro) che il server non sia attivo non genererà semplicemente un errore ma mostrerà solo dati vuoti / vuoti.

Esistono linee guida o buone pratiche accettate per questo tipo di situazione?

error-handling javascript angularjs

posta Pace 08.10.2015 - 00:32

fonte

1 risposta

Leggi altre domande sui tag error-handling javascript angularjs

Prestazioni di stored procedure Classe figlio che accede al metodo dei suoi genitori dal metodo Ancestor

score 2 · Answer 1

Il mio schema preferito è che il livello API restituisce una promessa che viene risolta se la chiamata ha esito positivo (indipendentemente dal fatto che abbia trovato o meno dati) e rifiutata solo se la chiamata ha avuto esito negativo.

Una chiamata a getCurrentUser , ad esempio, dovrebbe restituire un utente o dirmi che l'utente non esiste o che non ho permessi adeguati o varie altre cose. Se fa una di quelle cose che dovrebbe fare, la stessa chiamata api ha successo e il risultato dovrebbe essere restituito al chiamante. Se invece, ottengo un codice di errore 4xx o 5xx, la chiamata non è riuscita e il chiamante deve essere informato.

Lascia che lo strato api si preoccupi di effettuare la chiamata e restituire i dati. Lascia che il livello dati si preoccupi dell'interpretazione dei dati e dell'aggiornamento dei modelli. Consenti allo strato dell'interfaccia utente di presentare i dati e di notificare all'utente se si è verificato un errore.