Design Pattern per riprovare e gestire gli errori

Question

Design Pattern per riprovare e gestire gli errori

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

4

Sto cercando di trovare un buon modello di progettazione, o forse una serie di pattern, per iniettare la gestione degli errori e riprovare la gestione durante il recupero dei dati da un webservice.

Ad esempio, ho:

do {
    //get the data here
    data = Datagetter.getMyData(request)


    if(data.hasError())
    {
        //handle error
    }
} while(shouldRetry());

E sto cercando di capire un modo per iniettare il meccanismo che scopre e affronta qualsiasi errore, così come il meccanismo che gestisce il modo in cui un nuovo tentativo funziona (dovrei aspettare? ? ecc.)

Direi che non sono la prima persona a dover affrontare questo, e c'è un modo per farlo che non ho ancora scoperto.

Ho esaminato catena di responsabilità e strategy come possibili soluzioni, ma non riesco a sembrarle abbastanza complicate per funzionare.

error-handling dependency-injection design-patterns

posta MirroredFate 22.06.2015 - 19:48

fonte

4 risposte

Leggi altre domande sui tag error-handling dependency-injection design-patterns

tecnica per controllare le modifiche nel file di configurazione durante l'avvio di un programma Inserimento della convalida nei test basati sui dati

score 1 · Answer 1

Che lingua stai usando? A seconda della lingua (sincronizzata, asincrona) avrai diverse soluzioni.

Se è JavaScript, la promessa è davvero la strada da percorrere. Promises in JavaScript

Se è qualcosa come C #, probabilmente non vuoi avere un ciclo come hai indicato, perché bloccherai il thread. In tale scenario, esaminerei la configurazione del sistema di accodamento in combinazione con Modello di disegno comandi :

rabbitMQ | 0mq

Utilizzando la coda è possibile inviare messaggi non riusciti nella coda dei tentativi e riprovarli nell'ordine in cui sono stati inviati, potenzialmente con un certo ritardo.

score 1 · Answer 2

Ci sono molte cose da considerare qui. Vale la pena leggere le specifiche HTTP, in particolare sulle regole idempotenti, e considerare anche uno stile RESTful di interfaccia webservice.

In breve, se si implementa un servizio web con GET o HEAD, in teoria dovrebbe essere sicuro chiamare più volte con gli stessi parametri, ma i servizi web implementati come POST, PUT o DELETE dovrebbero essere chiamati una sola volta, e se falliscono, non dovrebbero essere riprovati senza considerare le conseguenze di richieste multiple.

La teoria è che se stai ottenendo una risorsa, più risorse per la stessa risorsa dovrebbero essere logicamente equivoche e che non ci sono conseguenze sullo stato del server per più richieste GET per la stessa risorsa. Se il verbo è un PUT, POST o DELETE, si prevede che la richiesta possa modificare lo stato dei dati del server, pertanto è probabile che le richieste multiple / ripetute abbiano effetti collaterali indesiderati.

Per gestire bene i tentativi, è necessario considerare l'errore verificatosi. Riprovare un errore causato da un 404 può essere gestito in modo diverso da un errore di timeout tcp, o da un reindirizzamento 301, e per capire cosa questo significhi nel contesto di questo URL.

score 0 · Answer 3

Hai esaminato la programmazione orientata all'aspetto?

collegamento

Forse aiuta?

Un'altra idea sarebbe quella di utilizzare una fabbrica astratta per restituire l'implementazione concreta di cui hai bisogno per gestire l'errore in fase di runtime.

score 0 · Answer 4

Ho paura che tu debba codificare la logica di riprovazione da solo. Tuttavia, questo può essere separato dalla chiamata di servizio effettiva utilizzando il modello Proxy. RetryingProxy esegue il wrapping del servizio effettivo e implementa la politica di gestione degli errori e riprogrammazione necessaria.