Come gestire gli errori meglio affrontati in un livello di astrazione più elevato e dipendenti dallo stato inferito nel livello corrente?

2

Ho un caso d'uso che può essere riparato, ma la logica per ripararla è meglio fatta con un livello più alto di astrazione. Il solo lancio di eccezioni / insuccessi è brutto perché è difficile passare indietro nello stack le informazioni necessarie al livello principale per sapere come risolverlo.

Per spiegare le specifiche, ho un programma che controlla più pezzi di hardware. Il livello 'top' è responsabile del calcolo di come far funzionare ciascun componente hardware, come generare "percorsi" di dati su hardware, ecc. Il mio livello successivo include thread per ogni singolo dispositivo. ogni thread del dispositivo genera e memorizza nella cache lo stato del dispositivo (recuperato da file di configurazione e hardware). I dispositivi elaborano le richieste dall'applicazione, individuano come aggiornare l'hardware per rendere tali richieste e quindi modificano lo stato della cache per riflettere le modifiche apportate. Finalmente ho dei plugin che inviano richieste fisiche all'hardware.

Di solito funziona bene, le richieste sono sequenziali per evitare problemi relativi alla corsa dei dati. Passiamo solo le informazioni su livelli, non abbiamo modo di ottenere aggiornamenti asincroni per il backup del livello. Tuttavia, è molto improbabile, ma possibile, che qualcuno possa cambiare fisicamente l'hardware senza passare attraverso il nostro sistema di controllo. Attenderemo fino a quando il plug-in rileva un errore nel tentativo di gestire una richiesta, e solo dopo proviamo ad aggiornare il nostro stato per quel componente hardware per vedere se una modifica ha causato l'errore (il monitoraggio costante è una funzionalità successiva).

Il mio problema è che quando viene rilevata una modifica su un dispositivo, in genere ciò significa che è stata apportata una modifica ai dispositivi collegati. Quando rilevo questo, voglio tracciare la modifica al dispositivo connesso, aggiornare il loro stato ecc. Fino a quando non ho trovato tutte le modifiche (questo non richiede l'aggiornamento di tutti i dispositivi tutti , solo quelli connessi). Ogni thread del dispositivo è responsabile solo di un dispositivo, quindi non può tracciare il cambiamento attraverso altri dispositivi senza propagare l'eccezione su un livello. Tuttavia, ho bisogno di sapere esattamente quali cambiamenti sono stati rilevati sul dispositivo per sapere quali dispositivi connessi dovrei aggiornare lo stato di. Se lancio un'eccezione, questa conoscenza viene persa e deve essere ricalcolata, il che è un costo piccolo ma reale a causa del tempo necessario per comunicare con l'hardware.

La cosa allettante da fare è chiamare un metodo nel mio livello applicazione dicendo "questo cambiamento è stato rilevato, vai ad aggiornare tutto il resto relativo ad esso". Tuttavia, questo rende i guidatori consapevoli del livello sopra di loro, che non è buono. Un'altra opzione è quella di propagare semplicemente l'errore e lasciare che il mio strato applicativo noti l'errore e quindi tornare allo stesso dispositivo per chiedere cosa ha cambiato e aggiornare tutto lo stato, quindi ricalcolare le modifiche da apportare e rendere la richiesta indietro al livello del dispositivo. Il primo è un odore di codice ovvio, il secondo sembra più codice, logica ridondante e penalità di piccola velocità (ci vuole un po 'di tempo per ottenere lo stato dall'hardware). Ci sono altre opzioni?

    
posta dsollen 17.05.2014 - 02:25
fonte

1 risposta

1

Questo sembra un lavoro per il modello di osservatore. Ogni dispositivo viene osservato dai dispositivi collegati. Sei sicuro di aver bisogno del livello genitore per essere coinvolto?

A meno che non ci sia qualcos'altro da fare, il genitore deve semplicemente gestire queste eccezioni sul dispositivo recuperandolo, impostandolo come modificato e facendo scorrere gli osservatori connessi dicendogli cosa devono sapere per recuperare.

Se un recupero di un hop è sufficiente, hai finito. Se è necessario consentire al recupero di propagare alcuni n hop fissi, è necessario un po 'di logica di arresto o si sovrapporrà a tutto. Hai già detto che non ti serviva.

Dopo tutto ciò lancia un'eccezione per dire educatamente al livello genitore che la richiesta è morta perché un po 'di goofball ha fatto casino con l'hardware. Accertati di aver recuperato dai loro shenanigans e sei pronto per la prossima richiesta.

Hai impostato tutto questo assicurandoti che ogni volta che c'è una connessione tra due dispositivi i due dispositivi si registrino come osservatori l'uno dell'altro.

    
risposta data 17.05.2014 - 08:57
fonte

Leggi altre domande sui tag