È giunta l’ora di vedere insieme come effettuare il debug del nostro codice scritto in java, con Eclipse e NVDA.
Il debug è una pratica molto comune per esaminare step by step il codice prodotto, per scovare bug gravi o anche semplici malfunzionamenti. Come prerequisito, bisogna avere letto il mio articolo “Guida introduttiva all’IDE Eclipse, per programmare con Java in modo accessibile” (per la configurazione di Eclipse e il suo addon che ne migliora l’accessibilità) o conoscere già la programmazione ad oggetti con java ed Eclipse. Naturalmente, anche il focus di questo articolo, sarà il mondo dell’accessibilità e delle metodologie di programmazione applicate alle persone con disabilità visiva.
Debug di applicazioni java
Per adesso, ci concentreremo sul debug di semplici applicazioni java, non vedremo ora il debug di applicazioni web per intenderci, ma quello di classici programmi che presentano una classe main. Ci concentreremo sul debug riga per riga, riuscendo a visionare il contenuto delle variabili o il risultato delle espressioni.
Eseguire una applicazione in debug, è paragonabile alla classica esecuzione che facciamo con “ctrl+f11”, con la differenza che possiamo esplorare a runtime il nostro codice e ad esempio capire il valore delle variabili senza usare dei classici System.out qua e la nel codice. Ma il debug non si limita a ciò e vedremo quanto è potente.
Quindi, anche quando saremo in debug, vedremo gli output nella view “console” di Eclipse e ci potremo spostare nelle altre view nel modo in cui facciamo solitamente.
Il concetto di breakpoint
Come dice la traduzione del termine stesso, un breakpoint, non è altro che un punto di interruzione. Noi possiamo inserire tali interruzioni nel nostro codice, solitamente inseriamo breakpoint in corrispondenza di una specifica riga, dalla quale vogliamo visionare step by step il nostro codice. La scorciatoia da tastiera per inserire un breakpoint in una data riga è “ctrl+shift+b” da premere mentre si è nell’editor di Eclipse in corrispondenza della riga interessata.
Se abbiamo installato e configurato l’addon Eclipse Enhance, quando premiamo tale combinazione, la sintesi vocale annuncerà “breakpoint on” indicandoci che il punto di interruzione è stato correttamente inserito. Se sulla medesima riga premiamo nuovamente la combinazione, lo screen reader pronuncerà “breakpoint off”.
Oltre a questo, se ci spostiamo con “freccia giù” nell’editor di Eclipse, potremo sentire un suono, il classico beep, in corrispondenza di ogni breakpoint che incontreremo.
Partiamo con il debug
Per eseguire il nostro codice in modalità debug, per una semplice applicazione java, basta premere “f11” mentre si è nell’editor di Eclipse, con aperta la classe contenente il main.
Naturalmente ha senso andare in debug se almeno un breakpoint è presente nelle nostre classi, non obbligatoriamente nella classe con il main. Altra cosa fondamentale è che il flusso delle istruzioni del nostro programma passi per quel dato breakpoint.
Ci accorgiamo che il debug non incontra breakpoint se nella sua esecuzione non si ferma mai e l’esecuzione è del tutto identica a quella classica fatta con “ctrl+f11”.
La perspective debug
Quando si va in debug con “f11”, Eclipse ci propone di cambiare perspective, passando a quella di debug. Naturalmente accettiamo il cambio.
Potremo poi tornare in ogni momento, magari a debug terminato, alla perspective “java”, con la combinazione “ctrl+f8”.
Ci sono molte view aggiuntive utilissime in questa nuova perspective, solo per citarne una quella denominata “breakpoints” che contiene appunto l’elenco dei punti di interruzione.
Poi saranno presenti quelle che già conosciamo, come “editor” e “console”.
Lanciato il debug, nel caso la nostra applicazione permetta degli input da console o interazioni varie, il flusso sarà sempre il medesimo di come se l’avessimo eseguita normalmente. Se si incontra un breakpoint, dovreste sentire un suono, un beep + forte del solito e il focus dovrebbe passare automaticamente all’editor, nel punto in cui è presente il breakpoint. Anche questa del suono è una feature dell’addon Eclipse Enhance.
Se il focus non passa automaticamente all’editor e a voi sembra invece che siete bloccati in un breakpoint, andate voi a mano nell’editor premendo “f12”. Ciò può accadere in base al fatto che vi trovaste in un altra view al momento del debug o magari stavate interagendo con la view console.
È importante che sappiate muovervi tra le diverse view, in modo da non rimanere bloccati. Ricordate sempre che il flusso del debug è bloccato nell’editor di testo.
Procedere passo a passo: step into e step over
Ci sono due modalità per muoversi nel codice passo a passo:
- step over: si procede riga per riga, senza entrare dentro a metodi. Se in un dato punto del codice richiamiamo una classe o un metodo, magari con un dato di ritorno, usanto lo step over, si attende che l’esecuzione di tale metodo sia terminata, prima di passare alla riga successiva. Lo step over, riga per riga, si fa premendo una volta “f6”, tale tasto ci fa andare avanti di una riga;
- step into: al contrario di quanto visto per lo step over, lo step into, ci fa entrare, ad esempio nel metodo dal quale si attende una risposta o una esecuzione. Lo step into si fa con “f5”.
Quando ci spostiamo con i comandi “f5” o “f6”, grazie all’addon Eclipse Enhance, udiremo un beep che ci segnalerà il passaggio sulla linea successiva. Questo è utilissimo con lo step over, nel caso dovessimo passare su una riga che necessita di un certo tempo di esecuzione, dobbiamo sapere in qualche modo quando termina e quando il debug passa alla linea successiva.
Passare al prossimo breakpoint
Come dicevamo, è possibile inserire più breakpoint, una volta esaminato il codice del primo, magari non era li il bug, vogliamo passare al prossimo, perchè ipoteticamente, il problema può essere nel prossimo blocco di codice. Farlo step by step potrebbe essere un lavoro molto lungo, quindi basta premere “f8” e il flusso di esecuzione tornerà normale, se serve si interagirà con il software e si arriverà al prossimo breakpoint. Analogamente, se non ci sono più breakpoint attivi e si preme “f8”, si terminerà la fase di debug.
Terminato il debug, potremo fare le eventuali modifiche del caso, salvare ed eseguire una nuova sessione di debug.
L’inspect delle variabili o delle espressioni
Come dicevamo in precedenza, una cosa molto comoda è la possibilità di vedere in realtime il valore delle variabili, delle espressioni o delle condizioni.
Mentre siamo in debug, posizionati nell’editor, basta selezionare una variabile, con i classici comandi di selezione del testo, solo il nome della variabile, senza il tipo e senza spazi e a testo selezionato premere “ctrl+shift+i”.
Apparirà una finestra di dialogo, suddivisa in due parti , sezioni in cui ci si può spostare con “f6”.
Nella prima sezione,rappresentata con una visualizzazione ad albero, sarà possibile esplorare la variabile e nel caso rappresenti un oggetto potremo esplorarne tutte le sue proprietà, quindi avremo sotto mano tutti i suoi valori in quel dato istante di debug.
La seconda sezione è composta da un’area di testo in cui è stampato il toString() dell’attributo selezionato nella area precedente.
Per chiudere la finestra, premere il tasto “esc”.
Allo stesso modo, potremo selezionare, al posto di una variabile, una condizione di un costrutto condizionale o di un ciclo per valutarne lo stato, in modo da capire se la condizione ha senso o se è stata progettata male.
Ricordo, che la riga su cui ci si trova, è da considerarsi eseguita solo dopo che il debug sarà passato alla riga successiva.
In conclusione
Ho cercato di illustrare il metodo più accessibile per effettuare il debug del codice java con Eclipse e NVDA.
Ci sono sicuramente altri modi per farlo e ci sono altre view molto utili nella perspective debug. Su tutte segnalo la view variables, strutturata ad albero, utile per consultare e cambiare al volo il valore delle variabili, e segnalo la view debug shell, utilizzata per eseguire a runtime porzioni di codice java. Potete provare ad esplorare tali view per capire se fanno al caso vostro.
Il debug è indispensabile quando dobbiamo mettere mano a codice scritto da altri o quando ci imbattiamo in un bug che proprio non riusciamo a risolvere.
Inoltre, a livello didattico, può servire ai neofiti per capire cosa accade a runtime, analizzare passo a passo il sorgente di un programma ci fa rendere conto di cosa accade in pratica.
A livello lavorativo è un mio valido alleato, lo uso spesso, lo preferisco alla lettura di interminabili log di errore, dai quali si potrebbe capire ugualmente il problema, ma essi risultano spesso prolissi di informazioni.
Lo utilizzo anche quando devo sviluppare una nuova feature, magari un po’ complessa, la prima esecuzione della stessa la eseguo sempre in debug, difficilmente funziona tutto al primo avvio, la distrazione, il bug o il malfunzionamento sono dietro l’angolo.
