Debug delle applicazioni

Ci sono alcuni modi.

Quello che stai usando è una forma rudimentale di logging . È probabilmente il modo più efficiente in termini di tempo per eseguire il debug della maggior parte degli errori. Vale la pena dedicare tempo a scrivere un modulo di registrazione solido che può essere reindirizzato allo schermo o al file, bufferizzato / non bufferizzato, ecc. Dovrebbe avere un timestamp e un messaggio, se non altro.

Ci sono anche eccezioni di lancio - questo può essere più utile con le lingue che eseguono una traccia di stack usando simboli, ad esempio Java o Python. Perl può gracidare () o morire () con informazioni altrettanto utili.

Un altro metodo sta avendo una vasta gamma di test unitari in grado di raccogliere errori in modo raffinato. Ciò ovviamente implica test ben scritti.

Quanto sopra sono essenzialmente metodi non interattivi.

Esiste anche Ye Old Interactive Debugger, che funziona in vari livelli di utilità a seconda dell'ambiente di sviluppo. Probabilmente Lisp dispone delle migliori funzioni di debug disponibili; C # ha probabilmente l'interfaccia utente più sviluppata. I debugger interattivi possono essere molto utili quando il tuo codice "logicamente" dovrebbe funzionare, e hai davvero bisogno di fare qualche serio controllo della variabile e sondare la situazione. È probabilmente il metodo più inefficiente e difficile da replicare di tutti i metodi, ma può essere davvero utile.

Il debugger interattivo può essere esteso per far sì che varie variabili e script vengano eseguiti su variabili che raggiungono valori, ma non sono sicuro che gli ambienti correnti lo supportino - l'ultimo che ho sentito è stato sviluppato nel '93 per ... Prolog ? Non riesco a ricordare la parte superiore della mia testa.

Un metodo che è stato studiato nei primi anni '80 e che sta avendo un ritorno minore oggi è rigiocabile / reverse debugging. Sto lavorando per farlo nella mia tesi per un sistema embedded altamente esotico.

Stai lentamente ma sicuramente reinventando il concetto di "logger", in cui le tre invenzioni di cui hai bisogno sono:

• Un'indicazione di gravità del messaggio. È questa banale informazione di debug o una notifica che il sistema del disco è corrotto?
• La possibilità di saltare i messaggi che non ti interessano.
• Una necessità per un messaggio di andare da qualche altra parte che sulla tua console.

Altri hanno fatto lo stesso prima di te e hanno affinato e lucidato l'idea fino a quando non hanno ottenuto un quadro che ti permettesse di dire cose come:

} catch (Exception e) {
  log.error("Subsystem X threw exception!", e);
}

Il sottosistema logger decide quindi se questo messaggio deve essere registrato, dove deve andare, così come raccogliere l'eccezione generata in modo che possa andare con il messaggio. Potrebbe essere salvato in un secondo momento in un file di testo, inviato come e-mail o notificato nel tuo programma di messaggistica istantanea preferito. Questo può essere molto utile per analizzare i problemi dopo che si sono verificati.

Ho scritto un'introduzione su come iniziare a utilizzare la registrazione in Java, che potresti trovare interessante, indipendentemente dalla lingua che usi. Vedi link

A volte le dichiarazioni cout sono più facili da fare, ma penso che le eccezioni siano la strada da percorrere nella maggior parte dei casi.

Uso sempre couts / trace - trovo che il debugging in stile breakpoint spesso interrompa troppo il mio processo di pensiero e rende più difficile seguire effettivamente l'esecuzione. A volte, tuttavia, il debugging dei punti di interruzione è assolutamente inestimabile. Penso che sia importante avere familiarità con diversi stili di debug e scegliere il migliore per ogni caso: interruzione di una mossa del mouse sarebbe un inferno, per una cosa ...