Uso sempre System.out.println(...) per eseguire il debug del mio codice, e funziona piuttosto bene. In quali casi usi eclipse java debugger? Non ho mai dovuto usarlo e il piccolo simbolo bug è ancora un po 'misterioso per me. Ci sono casi in cui il debugger mi aiuta che non riesco a risolvere con un println?
Ogni caso ...
Certo, non sono sicuro al 100% degli IDE Java (e gradirei eventuali correzioni non coerenti con gli IDE Java) perché uso Visual Studio su C # / F # ma aggiungo variabili all'elenco di controllo e utilizzo di interruzioni condizionali sostituisce completamente println ...
E diavolo, non sono nemmeno così bravo con il debugger, ma sono ancora anni luce prima del debug della console o di scavare nei log.
Il problema con il debug di println è che le stesse stampanti sono un problema.
Quando esegui il debug utilizzando println , devi modificare il codice per farlo. Ciò significa che devi già sapere, o almeno avere una buona idea, dove si trova il bug prima di iniziare il debug. E se già lo sapete, probabilmente non avrete bisogno di eseguire il debug comunque, poiché (almeno per IME) il motivo principale per il debug è trovare dove si trova un bug, non capire come risolverlo. Una volta che il bug è stato bloccato, la soluzione è solitamente ovvia solo dal contesto. (Non sempre, ovviamente, ma di solito.)
Se la tua diagnostica di stampa non si rivela utile per fornirti informazioni utili o non ti fornisce informazioni utili sufficienti , devi chiudere il programma, cambiare il codice, ricompilare e poi tornare a il punto in cui eri a riprodurre il bug.
Una volta che hai finito di trovare e correggere il bug, devi quindi cambiare di nuovo il codice per rimuovere le istruzioni println. (Speriamo che non ne manchi e poi spedisci il prodotto con l'output di debug rimasto!)
Un debugger interattivo non ha questi problemi. Non hai bisogno di sapere cosa stai cercando in anticipo; puoi esaminare i valori di qualsiasi variabile arbitraria in qualsiasi momento nel suo ambito. Non è necessario modificare il codice, perché il debugger è esterno al programma. E quindi non è necessario interrompere il debug, modificare il codice e ricompilare per cercare qualcosa di nuovo.
Solo questo principio - ispezionare il codice dall'esterno invece di doverlo strumentare manualmente (e quindi non-strumentarlo) - è la ragione per cui i debugger interattivi sono diventati il metodo preferito di debugging tra i programmatori moderni.
Non ci sono realmente informazioni che un debugger possa darti che non potresti ottenere attraverso la dichiarazione di stampa, ma ...
è molto più veloce e flessibile. Le parole non possono descrivere il potere che ottieni quando puoi guardare liberamente ciò che il codice sta facendo mentre è in esecuzione .
Tutto sommato, stimerei che l'uso di un debugger acceleri tipicamente il processo di debug 10 volte. Probabilmente 100 volte nei casi in cui vi è una lunga build o implementazione tra il momento in cui una dichiarazione di stampa fornisce informazioni su dove andare, ad esempio dove aggiungere un'altra dichiarazione di stampa e il tempo in cui è possibile vedere l'output di quella nuova stampa. In un debugger, basta un solo clic, forse mezzo secondo. Se devi eseguire una ricostruzione completa e distribuirla su un server di app, potrebbe impiegare mezz'ora.
nella mia esperienza, il debugger di Eclipse (o qualsiasi debugger passo passo, per quella questione) aiuta molto di più delle istruzioni println, perché:
(questi sono solo i vantaggi più basilari che ho trovato)
Tuttavia, il debugger non è sempre così carino:
in breve: per progetti piccoli e maneggevoli un debugger è il tuo più grande amico. Per i progetti di grandi dimensioni (su cui spesso lavori con molte persone), un ampio registro in scrittura è il tuo amico ancora più grande. O almeno il mio.
Dovresti prima cercarlo su google. Il debugger in Eclipse contiene già molte funzioni che non è necessario definire. Oltre a ciò, le istruzioni System.out.println () potrebbero essere utili per te in un semplice progetto di piccole dimensioni, ma in un progetto in cui molti membri funzionano o hai un numero elevato di file, non puoi continuare ad aggiungere queste istruzioni. È bello avere punti di interruzione.
Ti suggerisco di dare un'occhiata a questo
Non trovo quasi mai che ho bisogno del debugger, ma quando ne ho bisogno ne ho davvero bisogno.
Un caso spiacevole è dove usi println per stampare un oggetto, e stampa "nulla". Dopo aver osservato il codice per anni, si è convinti che l'oggetto non può essere nullo a quel punto. Eppure, questo è ciò che dice println . Questo può perdere ore.
Nel debugger, troverai immediatamente che l'oggetto non è null . Tuttavia, il metodo toString() è stato sovrascritto per stampare il valore di qualche campo in quell'oggetto. Il valore di questo campo è, ovviamente, null .
Il debugger ti consente di esplorare una gamma più ampia di domande, più rapidamente, rispetto all'utilizzo di println . Ma in molte situazioni semplici, println è abbastanza buono. Basta non sprecare troppo tempo in quei casi in cui non è abbastanza buono.