Come trovare la causa di un'eccezione nel codice asincrono

1

Mi capita spesso di provare a seguire il mio codice per scoprire da dove proviene l'eccezione.

L'esempio tipico è quando qualche parsing fallisce, e io prendo l'execption. Quindi trascorro una quantità ridicola di tempo usando i breakpoint e step-in / step-out / step-over per vedere l'analisi esatta che non ha funzionato. Perché molti metodi e molte chiamate diverse usano quel parsing specifico, e non posso sapere con certezza quale sia stata la causa.

In questo momento, se il codice di produzione è "solido" e c'è un bug che viene ogni tanto, mi viene davvero difficile trovarlo semplicemente riproducendo e saltando ogni riga una per una. E per quello che vale, anche se funziona sempre, è così tedioso.

C'è qualcosa che sto sbagliando? Forse la mia architettura è sbagliata? Non ho alcun codice da mostrare, ma se qualcun altro avesse mai provato la stessa sensazione o lo fosse per esperienza, sarei felice di imparare qualcosa!

    
posta Gil Sand 11.02.2016 - 14:21
fonte

1 risposta

3

Colui che ha progettato il sistema prima che venissi qui includeva un oggetto "Unità di lavoro" che poteva contenere un risultato dell'operazione asincrona (un tipo T) e qualsiasi errore verificatosi, incluse eccezioni e tracce dello stack.

Detto questo, non sono esattamente un fan del suo stile architettonico; è troppo complicato e ho i miei dubbi sull'efficacia di mettere async ovunque.

Quindi ecco i miei suggerimenti:

  1. Implementa async solo dove sai che farà la differenza. Il caso d'uso principale per la funzionalità asincrona è di mantenere un'interfaccia utente reattiva. Per operazioni di background lunghe non correlate all'interfaccia utente, esistono meccanismi migliori. Non implementare async solo perché è possibile; assicurati di ottenere un vantaggio in cambio di tale complessità aggiuntiva.

  2. Scrivi codice che è testabile dell'unità. Se puoi dimostrare che il codice funzionerà da solo come funzione autonoma, allora funzionerà anche in un contesto asincrono e hai vinto Non c'è bisogno di fare di tutto per eseguire il debug in un contesto in esecuzione.

  3. Fai un uso migliore delle funzionalità di debug dell'IDE. Non hai specificato quale linguaggio di programmazione e ambiente stai utilizzando, ma Visual Studio ha la capacità di fornire dettagli sulle eccezioni nidificate , compresi quelli che si verificano in un contesto asincrono o thread.

  4. Diventa un maestro al logging. La registrazione non ti dice solo quando e dove si verificano problemi, ma ti aiuta anche a capire come funziona il software e ti dà informazioni continue sul suo salute.

Il più importante di questi? Numero 2. È molto più semplice risolvere il problema al di fuori dei contesti asincroni o thread.

    
risposta data 11.02.2016 - 17:21
fonte

Leggi altre domande sui tag