Ghid C#, Cod de depanare
În C#, ca și în alte limbi care au apărut înainte de .NET, tehnica principală de depanare este de a adăuga puncte de întrerupere și de a examina ce se întâmplă în cod în anumite momente în timpul execuției sale.
Puncte de întrerupere
Dacă oprirea la o anumită linie de fiecare dată nu este lucrul potrivit pentru a rezolva problema, puteți crea un așa-numit punct de întrerupere condiționat. Pentru a face acest lucru, selectați elementul din meniul Debug (Depanare) Windows --- Breakpoints (Fereastră --- Breakpoints). Se va deschide o casetă de dialog care vă permite să specificați detaliile dorite pentru punctul de întrerupere. În această fereastră, puteți efectua următoarele acțiuni:
Specificați că execuția trebuie întreruptă numai după ce punctul de întrerupere a fost depășit de un anumit număr de ori.
Specificați că punctul de întrerupere ar trebui să aibă efect la fiecare a n-a linie este atinsă, de exemplu, la fiecare a 20-a execuție de linie (acest lucru este util la depanarea buclelor mari).
Setați puncte de întrerupere pe variabile, nu comenzi. În acest caz, valoarea variabilei specificate va fi monitorizată, iar punctele de întrerupere vor fi activate de fiecare dată când valoarea acestei variabile se schimbă. Totuși, această opțiune poate încetini foarte mult execuția codului, deoarece se va cheltui timp suplimentar de procesor pentru a verifica dacă valoarea variabilei urmărite s-a schimbat după executarea fiecărei instrucțiuni.
Fila Autos vă permite să vizualizați valorile ultimelor variabile care au fost accesate în timp ce programul rula.
Fila Locals vă permite să vizualizați valorile variabilelor care sunt accesate în metoda în execuție curentă
Fila Watch vă permite să vizualizați valorile oricăror variabile de interes pentruprin specificarea explicită a numelor lor direct în fereastra Watch.
Excepții
Excepțiile sunt un instrument excelent pentru a asigura gestionarea corectă a erorilor într-o aplicație livrată. Când sunt utilizate corect, acestea oferă încredere că aplicația va putea face față dificultăților, iar utilizatorul nu va vedea niciodată o casetă de dialog cu o descriere tehnică a problemei. Din păcate, în timpul depanării, excepțiile nu sunt atât de mari. Există două motive pentru aceasta:
Dacă apare o excepție în timpul depanării, de multe ori nu doriți ca aceasta să fie gestionată automat, mai ales dacă înseamnă închiderea grațioasă a programului. Dimpotrivă, depanatorul ar trebui să vă ajute să aflați de ce a apărut această excepție. Desigur, dificultatea constă în faptul că, în cazul scrierii unui cod de înaltă calitate, fiabil și tolerant la erori, programul se va ocupa automat de aproape totul, inclusiv de problemele care trebuie detectate.
Dacă apare o excepție pentru care nu a fost furnizat niciun handler, runtime-ul .NET va încerca totuși să o găsească. Din păcate, în momentul în care detectează că handlerul nu există, programul se va termina. Prin urmare, nu va mai rămâne nicio stivă de apeluri și va fi imposibil să vizualizați valorile oricăror variabile, deoarece toate vor fi în afara domeniului de aplicare.
Desigur, puteți seta puncte de întrerupere în blocurile catch, dar acest lucru de multe ori nu ajută prea mult, deoarece atunci când este atins blocul catch, fluxul de control, prin definiție, va părăsi blocul try corespunzător. Aceasta înseamnă că variabilele ale căror valori ar fi trebuit, cel mai probabil, să fie examinate pentru a afla ce a mers prost vor ieși din domeniul de aplicare. Nici măcar nu vacapacitatea de a se uita la urmărirea stivei pentru a afla ce metodă se executa în momentul declanșării instrucțiunii throw, deoarece controlul ar fi părăsit deja acea metodă. Desigur, punerea unui punct de întrerupere în instrucțiunea throw va rezolva această problemă, dar rețineți că atunci când scrieți codul într-un mod protejat, vor exista o mulțime de instrucțiuni throw în cod. Cum să ghicim atunci care dintre ele funcționează și duce la generarea unei excepții?
De fapt, Visual Studio oferă o soluție foarte puternică. Dacă vă uitați în meniulDepanare (Depanare), atunci puteți găsi articolul Excepții (Excepții) acolo. Selectarea acestui element deschide caseta de dialog Excepții. Această fereastră vă permite să specificați ce ar trebui să se întâmple atunci când este aruncată o excepție. Aici puteți specifica că execuția ar trebui să continue sau să se oprească cu trecerea la modul de depanare, caz în care se va opri, iar depanatorul va fi chiar pe instrucțiunea throw:
Visual Studio este conștient de toate clasele de excepții care sunt disponibile în clasele de bază .NET și multe astfel de excepții care pot fi aruncate în afara mediului .NET. Visual Studio nu recunoaște automat clasele de excepții speciale care sunt aruncate de dezvoltatori, dar vă permite să adăugați manual astfel de clase de excepții la listă și, prin urmare, să specificați care dintre aceste excepții ar trebui să conducă la o terminare imediată a aplicației. Pentru a face acest lucru, faceți clic pe butonul Adaugă, care este activat atunci când selectați cel mai de sus nod din arbore și introduceți numele clasei de excepție personalizată.
Comenzi suplimentare de depanare sursă
Compilarea aproape a întregului software comercial în stadiul de depanare și în stadiul depregătirea versiunii finale a produsului ar trebui efectuată puțin diferit. Visual Studio este capabil să înțeleagă acest lucru deoarece stochează informații despre toate opțiunile pe care ar trebui să le transmită compilatorului. Pentru a susține diferite versiuni ale unui proiect Visual Studio, va trebui să stocați aceste informații în mai multe instanțe. Diferitele instanțe ale unor astfel de informații sunt numite configurații. La crearea unui proiect, Visual Studio oferă automat două astfel de configurații din care să aleagă, care sunt numite, respectiv,Debug (Debug) șiRelease (Release) :
Configurația Debug specifică de obicei că nu trebuie efectuate optimizări, informații suplimentare de depanare ar trebui să fie prezente în codul executabil, iar compilatorul ar trebui să presupună că simbolul de depanare a preprocesorului Debug este definit în cod, cu excepția cazului în care este suprascris în mod explicit cu directiva #undefined .
Configurația Release specifică faptul că compilatorul ar trebui să efectueze optimizări pe codul compilat, nicio informație suplimentară nu trebuie să fie prezentă în codul executabil și compilatorul nu ar trebui să asume prezența simbolului preprocesorului Debug.
De asemenea, vă puteți defini propriile configurații. Acest lucru este necesar, de exemplu, pentru a construi o aplicație cu mai multe versiuni diferite. Anterior, din cauza problemelor cu suportul Unicode pe Windows NT, dar nu pe Windows 95, era obișnuit ca multe proiecte C++ să creeze două configurații - una pentru Unicode și alta pentru MBCS (set de caractere multibyte).