Łatwiejsze debugowanie w .NET (DebuggerDisplay i ToString)

Po staremu

Typowa, prosta klasa Person.  Cztery właściwości i konstruktor.

Gdy w dowolnym miejscu programu zostanie utworzona instancja klasy Person, a następnie debuggerem zatrzyma się wykonywanie kodu, można sprawdzić stan naszego obiektu.

Nagłówek obiektu wyświetla nazwę klasy, a jego rozwinięcie wyświetli poszczególne składowe i ich wartości. Podobny efekt jest widoczny jeśli utworzy się kolekcję obiektów Person i podejrzy stan jej elementów.

Proste.

Ale problem jednak jest taki, że widzimy listę 5 obiektów Person i na pierwszy rzut oka nic więcej o nich nie wiemy. Trzeba każdego rozwinąć i sprawdzić co to za obiekt.

O wiele lepiej jest gdy oglądamy w ten sposób kolekcję liczb, albo stringów.

Oczywiście 2 przykład jest lepszy, bo jeśli mamy w kolekcji 100 czy 200 elementów to od razu widać wartości tych elementów.

Na szczęście są sposoby aby sobie ułatwić życie.

ToString()

Pierwszy sposób, to przeciążenie metody ToString().

Jak wiadomo, każdy obiekt w .NET dziedziczy po typie object, a więc posiada interesującą nas metodę. Domyślnie ToString() dla klasy Person zwraca jej nazwę (namespace + nazwa klasy), a ta informacja wyświetla się np. w debugerze. A więc napiszmy własny kod dla ToString().

Prosty kawałek kodu, który zwraca imię, nazwisko i wiek osoby.

Teraz gdy będziemy debugować np. listę obiektów typu Person będzie zdecywodanie bardziej czytelnie:

Od razu widać kto jest kim, nie ma potrzeby rozwijania poszczególnych elementów kolekcji.

DebuggerDisplay

Drugim sposobem jest zastosowanie atrybuty DebuggerDisplay. Atrybut ten dostępny jest w przestrzeni System.Diagnostics. Dodajemy go do klasy, dla której chcemy zmieniać format wyświetlania informacji w debuggerze.

Efekt jest bardzo podobny jak przeciążenie metody ToString()

Wady i zalety

Zaletą atrybutu DebuggerDisplay jest większa elastyczność na literówki, błędy formatowania, null’owe referencje w stosunku do rozwiązania z ToString().

Można też wyświetlać informacje bardziej złożone. Jeśli klasa Person dodatkowo posiada właściwość Address, i chcemy wyświetlać w debuggerze nazwę miasta…

… a właściwość Address będzie null’em, to w normalnych okolicznościach może pojawić się wyjątek NullReferenceException. Na szczęście go nie zobaczymy, ponieważ debugger wyświetli nazwę klasy.

Ale wyjątek pojawi się gdy jawnie wywołamy na zmiennej john metodę ToString().

Jawne wywołanie metody gwarantuje wyjątek.

O wiele lepiej (bezpieczniej) jest jeśli użyjemy drugiego sposobu. Wystarczy zmienić format w DebuggerDisplay na wyświetlanie FirstName, LastName i Address.City

… i zobaczymy wszystko co tylko się da, a reszta zostanie opisana jako null.

Co więcej, w DebuggerDisplay można wpisywać też nazwy metod, więc jest to dość elastyczny mechanizm.

Reklamy

8 thoughts on “Łatwiejsze debugowanie w .NET (DebuggerDisplay i ToString)

  1. No to jak już jesteśmy przy ułatwianiu debuggowania, to warto jeszcze wspomnieć o kolejnym atrybucie, który bardzo często się przydaje: DebuggerStepThrough.

  2. Pingback: dotnetomaniak.pl

  3. Bardzo fajny atrybut.
    Przydaje się jeśli masz wywołanie metody z 10 parametrami (aczkolwiek ja nie popieram stosowania więcej niż 2 argumentów w metodzie) i chcąc wejść do niej (F11 Step-in) nie chcesz wchodzić do każdego get’a 🙂

    • Racja. Zmieniłem na „właściwości”. A swoją drogą, nie wiem czy to wchodzi do polskiego słowika programistycznego, czy nie, ale w ostatnim czasie coraz to częściej słyszę „propercja, propercje” od kolegów zamiast „właściwość” lub po prostu „property”…

      • ja jeszcze oprócz „właściwość” słyszałem także „własność”, która moim zdaniem też jest po polsku i ok 🙂

  4. doszedlem do konca po „propercjach” 😉 Nie znalem tego atrybutu „DebuggerDisplay „, dzięki!

  5. Pingback: Ukrywanie składowych klas w debuggerze (DebuggerBrowsable) | Wojciech Poniatowski

Możliwość komentowania jest wyłączona.