Questa è la classica finestra di debug, cosa mi fa capire esattamente?Cosa avviene fino a quel punto di codice?Se una variabile è stata inizializzata o meno?Non mi è chiaro il suo scopo, qualcuno mi schiarisce le idee?
Questa è la classica finestra di debug, cosa mi fa capire esattamente?Cosa avviene fino a quel punto di codice?Se una variabile è stata inizializzata o meno?Non mi è chiaro il suo scopo, qualcuno mi schiarisce le idee?
~Il nome di una variabile deve riflettere il suo scopo e non il suo tipo di dati, NET Framework.
Ti dice molte cose, tra cui il punto in cui è attualmente ferma l'esecuzione del programma e lo stato delle variabili del programma.
Amaro C++, il gusto pieno dell'undefined behavior.
Non solo ... direi che importantissimo e' lo stack delle chiamate, che ti da' visione della "vita" del codice nei passaggi tra le funzioni ...
@oregon
Questo riquadro, nella finestra di debug, è quello che mi è meno chiaro!Di che si tratta precisamente e in parole semplici?
~Il nome di una variabile deve riflettere il suo scopo e non il suo tipo di dati, NET Framework.
Beh ... non sempre si possono usare parole semplici ... a volte e' necessario usare le parole giuste ...
Comunque, quella finestra ti indica che l'esecuzione del codice si e' fermata nel costruttore della classe UserPreferences del modulo ConsoleApplication1 contenuto nell'eseguibile ConsoleApplication1.exe.
Questo costruttore era stato chiamato da "codice esterno" a questo programma (la linea precedente te lo dice), probabilmente dall'interno del framework o del runtime.
A sua volta, questo codice esterno era stato chiamato dal Main della classe MainEntryPoint che a sua volta era stato chiamato da "codice esterno" (vedi sopra) ...
... e cosi' via ... lo stack delle chiamate ti indica la successione di chiamate tra codice del runtime e codice utente ... per capire se c'e' stata la corretta sequenza (o quella che ci si aspettava) di chiamate tra le varie funzioni.
Permessi di invio
Rispondi quotando