Debugowanie — znajdź przyczynę, nie zgaduj

Czego się dziś nauczysz

Przygotowanie: lekcje 01–54. Przewidywany czas: 90 min z zadaniami. Przykłady wymagają .NET 8 lub nowszego, z włączonymi ImplicitUsings i Nullable.

Zgadywanie kontra patrzenie na dane

Program się kompiluje, uruchamia i daje zły wynik. Najczęstsza reakcja to zaglądanie w kod i zgadywanie: „może tu jest minus zamiast plusa”, „może zmienię tę nierówność”. Po dwudziestu minutach program działa inaczej, ale nadal źle, a Ty nie wiesz, co dokładnie zmieniłeś.

Druga najczęstsza reakcja to obsypanie kodu wypisywaniem:

Console.WriteLine("tu 1");
Console.WriteLine(suma);
Console.WriteLine("tu 2");
Console.WriteLine($"i = {i}, j = {j}, suma = {suma}");
Console.WriteLine("tu 3 !!!!!");

To już jest krok w dobrą stronę — patrzysz na dane, nie na kod. Ale ma trzy wady: musisz przewidzieć z góry, co wypisać; każda zmiana wymaga ponownej kompilacji; a na koniec trzeba to wszystko posprzątać, zwykle zostawiając jeden zapomniany wiersz.

Debugger robi to samo bez tych wad: zatrzymuje program w wybranym miejscu i pozwala obejrzeć każdą zmienną, bez zmieniania choćby jednego znaku w kodzie.

Na egzaminie zawodowym i w podstawie programowej pojawia się to jako trzy wymagania: rozpoznać zadania debuggera, przeanalizować nim błędy oraz poprawić i zoptymalizować kod. Wszystkie trzy przejdziemy po kolei.

Rozpoznanie zajmuje sekundę

Zanim sięgniesz po jakiekolwiek narzędzie, rozpoznaj rodzaj błędu. Każdy wymaga innego postępowania, a rozpoznanie zajmuje sekundę.

Błędy kompilacji — czytaj pierwszy, nie ostatni

int x = "5";                         // CS0029: nie mozna przekonwertowac string na int
Console.WriteLien("czesc");          // CS0117: Console nie ma metody WriteLien
if (x = 5) { }                       // CS0029: warunek musi byc bool (jedno = zamiast ==)
int y;
Console.WriteLine(y);                // CS0165: uzycie nieprzypisanej zmiennej

Błędy wykonania — komunikat mówi prawdę

Wyjątek nie jest karą, tylko raportem. Zawiera trzy rzeczy, a wszystkie trzy są potrzebne:

Unhandled exception. System.IndexOutOfRangeException: Index was outside the
bounds of the array.
   at Program.<Main>$(String[] args) in C:\kurs\Program.cs:line 14

Uczniowie najczęściej przewijają ten komunikat i mówią „wyskoczył błąd”. Tymczasem są w nim dosłownie odpowiedzi na pytania „co”, „gdzie” i „którędy program tam doszedł”.

Błędy logiczne — program kłamie z uśmiechem

Tu nie ma żadnego komunikatu. Program policzył średnią 4 zamiast 4,5 i zakończył się pomyślnie. Jedyny sposób, żeby to wykryć, to wiedzieć z góry, jaki wynik jest poprawny — i o tym jest następna sekcja.

Postępowanie, które zawsze działa

Debugger to narzędzie. Metoda jest ważniejsza i działa nawet bez narzędzia. Sześć kroków, zawsze w tej kolejności:

Przypadki testowe — trzy, których nigdy nie pomijaj

Zanim uznasz błąd za naprawiony, sprawdź nie jeden przypadek, a cztery:

Punkty wstrzymania, kroki i okna

Debugger to część środowiska, która uruchamia program pod nadzorem: potrafi go zatrzymać, wykonywać po jednym wierszu i pokazywać zawartość każdej zmiennej. Jest w Visual Studio, w Visual Studio Code i w Riderze — skróty różnią się nieznacznie, zasada jest ta sama.

Punkt wstrzymania

Punkt wstrzymania (breakpoint) to zaznaczony wiersz, przed którym program ma się zatrzymać. Stawia się go kliknięciem na lewym marginesie albo klawiszem F9. Pojawia się czerwona kropka.

Po uruchomieniu klawiszem F5 program dochodzi do tego wiersza i staje — jeszcze go nie wykonawszy. To ważne: wartości, które widzisz, są stanem przed wykonaniem zaznaczonego wiersza.

Cztery okna, które trzeba znać

W oknie zmiennych lokalnych obiekty i kolekcje da się rozwijać strzałką, żeby zobaczyć pola i elementy. Wartości można też zmienić w trakcie zatrzymania — przydaje się, żeby sprawdzić hipotezę bez ponownego uruchamiania.

Punkt wstrzymania z warunkiem

Pętla wykonuje się tysiąc razy, a błąd występuje przy setnym obiegu. Zatrzymywanie się sto razy jest bezsensowne. Prawy przycisk na czerwonej kropce → Warunki → wpisujesz warunek:

i == 100                 // zatrzymaj sie tylko w tym obiegu
suma < 0                 // zatrzymaj sie, gdy suma zrobi sie ujemna
u.Imie == "Kasia"        // zatrzymaj sie tylko przy tym obiekcie

Nazwa wskazuje kierunek szukania

Osiem wyjątków odpowiada za zdecydowaną większość przerwanych programów w projektach szkolnych. Warto je znać z nazwy, bo nazwa od razu wskazuje kierunek szukania.

Debug.Assert — pułapka na niemożliwe

Czasem chcesz zapisać w kodzie warunek, który musi być prawdziwy, i dowiedzieć się natychmiast, gdyby nie był:

using System.Diagnostics;

static double Srednia(int[] oceny)
{
    Debug.Assert(oceny.Length > 0, "tablica ocen nie moze byc pusta");

    int suma = 0;
    foreach (int o in oceny)
    {
        Debug.Assert(o >= 1 && o <= 6, $"nieprawidlowa ocena: {o}");
        suma += o;
    }

    return (double)suma / oceny.Length;
}

Debug.Assert działa tylko w kompilacji Debug — w wersji Release znika bez śladu i nie zwalnia programu. Nie służy do sprawdzania danych od użytkownika (do tego są wyjątki z lekcji 35), tylko do wyłapywania własnych pomyłek w założeniach. Wymaga using System.Diagnostics;, bo ta przestrzeń nie jest dodawana automatycznie.

Z tej samej przestrzeni pochodzi Debug.WriteLine — wypisuje do okna danych wyjściowych środowiska, a nie do konsoli programu, i również znika w wersji Release. To lepszy wybór niż Console.WriteLine do tymczasowych podglądów, bo nie trzeba go potem szukać i usuwać.

Zmierz, popraw algorytm, potem szczegóły

Gdy program działa poprawnie, ale za wolno, obowiązuje ta sama zasada co przy błędach: najpierw zmierz, potem zmieniaj. Zgadywanie, co jest wolne, myli się zaskakująco często.

Krok 1: zmierz

using System.Diagnostics;

Stopwatch zegar = Stopwatch.StartNew();

// ... kod, ktory mierzymy ...

zegar.Stop();
Console.WriteLine($"czas: {zegar.ElapsedMilliseconds} ms");

Krok 2: popraw algorytm

To tutaj są całe zyski. Przykład z lekcji 28 — szukanie duplikatów w tablicy 20 000 liczb:

// wersja 1: kazdy z kazdym - zlozonosc O(n^2)
int duplikaty = 0;
for (int i = 0; i < dane.Length; i++)
{
    for (int j = i + 1; j < dane.Length; j++)
    {
        if (dane[i] == dane[j])
        {
            duplikaty++;
        }
    }
}

// wersja 2: zbior unikalnych - zlozonosc O(n)
HashSet<int> widziane = new HashSet<int>();
int duplikaty = 0;
foreach (int x in dane)
{
    if (!widziane.Add(x))      // Add zwraca false, gdy element juz byl
    {
        duplikaty++;
    }
}

wersja 1 (O(n^2)):  1180 ms
wersja 2 (O(n)):       2 ms

Kilkaset razy szybciej — i to nie dzięki żadnej sztuczce, tylko dzięki zmianie algorytmu. Żadne „mikropoprawki” w wersji pierwszej nie zbliżyłyby się do tego wyniku.

Krok 3: dopiero teraz szczegóły

Sesja debugowania od początku do końca

Program ma policzyć średnią ocen trzech uczniów. Zawiera trzy błędy — po jednym z każdego rodzaju. Przejdziemy przez niego dokładnie tak, jak się to robi w praktyce.

// Program.cs - wersja z trzema bledami
string[] uczniowie = { "Kasia", "Marek", "Ala" };

int[][] oceny =
{
    new int[] { 5, 4, 3 },
    new int[] { 2, 6 },
    new int[] { 4, 4, 5, 5 }
};

int suma = 0;

for (int i = 0; i < uczniowie.Length; i++)
{
    for (int j = 0; j <= oceny[i].Length; j++)
    {
        suma += oceny[i][j];
    }

    int srednia = suma / oceny[i].Length;
    Console.WriteLine($"{uczniowie[i]}: {srednia}");
}

Krok 2 metody: co ma wyjść

Liczymy na kartce, zanim cokolwiek uruchomimy:

Pierwsze uruchomienie

Unhandled exception. System.IndexOutOfRangeException: Index was outside the
bounds of the array.
   at Program.<Main>$(String[] args) in Program.cs:line 16

Rodzaj: błąd wykonania. Komunikat mówi „indeks poza zakresem” i wskazuje wiersz 16, czyli suma += oceny[i][j];.

Stawiamy punkt wstrzymania na tym wierszu — ale z warunkiem, żeby nie klikać przez wszystkie obiegi. Warunek: j >= oceny[i].Length. Program zatrzymuje się dokładnie raz, a okno zmiennych lokalnych pokazuje:

i                 0
j                 3
oceny[i].Length   3
suma              12

Hipoteza: pętla dochodzi do j = 3, a ostatni poprawny indeks to 2. Winowajcą jest j <= oceny[i].Length — powinno być <. To klasyczny błąd „o jeden”.

Zauważ, że przy okazji dowiedzieliśmy się czegoś ważnego: suma wynosi 12, czyli poprawnie 5 + 4 + 3. Pierwsza część obliczeń jest dobra.

Drugie uruchomienie — po poprawce

Kasia: 4
Marek: 10
Ala: 6

Rodzaj: błąd logiczny. Kasia ma 4 — zgadza się z kartką. Marek ma 10 zamiast 4, Ala 6 zamiast 4,5. Wyniki rosną, więc coś się nie zeruje.

Punkt wstrzymania na wierszu z int srednia = ..., bez warunku — trzy zatrzymania, po jednym na ucznia. Obserwujemy suma:

Hipoteza: 20 = 12 + 8, a 38 = 20 + 18. Suma nie zeruje się między uczniami, bo int suma = 0; stoi przed pętlą zewnętrzną. Musi być w jej środku.

Trzecie uruchomienie

Kasia: 4
Marek: 4
Ala: 4

Dwa pierwsze wiersze się zgadzają. Ala ma 4, a powinna 4,5. Rodzaj: znowu błąd logiczny, tym razem bardzo cichy — różnica wynosi pół punktu i łatwo jej nie zauważyć, jeśli nie policzyłeś wyniku na kartce w kroku 2.

Zmienna srednia jest typu int, a 18 / 4 dla liczb całkowitych daje 4 z odrzuconą resztą. To pułapka z lekcji 09. Poprawka: typ double i rzutowanie licznika.

Krok 6: przypadki graniczne

Program daje już poprawne wyniki dla danych z zadania. Sprawdzamy trzy pozostałe przypadki z tabeli przypadków testowych i okazuje się, że uczeń bez żadnej oceny wywoła DivideByZeroException. Dopisujemy sprawdzenie.

Wersja końcowa

// Program.cs - wersja poprawiona
using System.Diagnostics;

string[] uczniowie = { "Kasia", "Marek", "Ala" };

int[][] oceny =
{
    new int[] { 5, 4, 3 },
    new int[] { 2, 6 },
    new int[] { 4, 4, 5, 5 }
};

Debug.Assert(uczniowie.Length == oceny.Length, "inna liczba uczniow i wierszy ocen");

for (int i = 0; i < uczniowie.Length; i++)
{
    int suma = 0;                                  // poprawka 2: zerowanie w kazdym obiegu

    for (int j = 0; j < oceny[i].Length; j++)      // poprawka 1: < zamiast <=
    {
        Debug.Assert(oceny[i][j] >= 1 && oceny[i][j] <= 6, $"zla ocena: {oceny[i][j]}");
        suma += oceny[i][j];
    }

    if (oceny[i].Length == 0)                      // poprawka 4: przypadek pusty
    {
        Console.WriteLine($"{uczniowie[i]}: brak ocen");
        continue;
    }

    double srednia = (double)suma / oceny[i].Length;   // poprawka 3: dzielenie rzeczywiste

    Console.WriteLine($"{uczniowie[i],-8} ocen {oceny[i].Length}  suma {suma,2}  srednia {srednia:F2}");
}

Kasia    ocen 3  suma 12  srednia 4,00
Marek    ocen 2  suma  8  srednia 4,00
Ala      ocen 4  suma 18  srednia 4,50

Podsumowanie sesji

Zestawienie elementów

Czego nie robić przy szukaniu błędu

Zadania

Co trzeba zapamiętać

• Debugowanie to ustalanie, gdzie program rozjeżdża się z oczekiwaniem; sama naprawa jest zwykle łatwa.
• Najpierw rozpoznaj rodzaj błędu: kompilacji, wykonania albo logiczny. Każdy wymaga innego postępowania.
• Przy błędach kompilacji poprawiaj pierwszy komunikat z listy, nie ostatni.
• Komunikat wyjątku zawiera rodzaj, opis, plik i numer wiersza — to gotowa odpowiedź, wystarczy ją przeczytać.
• Błąd logiczny nie daje żadnego komunikatu. Wykryjesz go tylko wtedy, gdy wiesz, jaki wynik jest poprawny.
• Metoda: odtwórz → policz oczekiwany wynik → zawęź połowieniem → postaw hipotezę → zmień jedną rzecz → sprawdź całość.
• Punkt wstrzymania zatrzymuje program przed wykonaniem zaznaczonego wiersza.
• F10 przechodzi ponad wywołaniem, F11 wchodzi do metody. Domyślnie używaj F10.
• Warunkowy punkt wstrzymania zastępuje setki naciśnięć F5 jednym zatrzymaniem w właściwym obiegu.
• Okno zmiennych lokalnych, czujki i stos wywołań odpowiadają na pytania „co”, „ile” i „skąd tu jestem”.
• Po każdej poprawce sprawdź cztery przypadki: typowy, graniczny, pusty i błędny.
• Debug.Assert i Debug.WriteLine znikają w wersji Release — służą do własnych założeń, nie do danych od użytkownika.
• Optymalizacja ma stałą kolejność: zmierz, popraw algorytm, dopiero potem szczegóły. I nigdy przed poprawnością.

Dokumentacja: Microsoft Learn — temat tej lekcji.