Dziś postaram się przybliżyć rzadko stosowaną technikę wyszukiwania błędów w kodzie. Polega ona na użycia drugiej instancji Visual Studio do znalezienia błędów w pierwszej. Patrząc na ostatnie zdanie można zacząć się zastanawiać jak szukanie błędów w Visual Studio może pomóc w znalezieniu błędów w naszym programie. Należy zdać sobie sprawę, że tak naprawdę Visual Studio zawiera w sobie nasz kod. I naszym celem jest prześledzenie działania tego kodu.
Sztandarowym przykładem zastosowania tej techniki jest naprawa okien lub kontrolek, które nie chcą wyświetlać się poprawnie w edytorze. W takiej sytuacji najczęściej dostaniemy informację, że wystąpił jakiś wyjątek. Bardzo często osoby z większym doświadczeniem są w stanie określić na podstawie tej informacji prawdopodobne miejsce błędu. Zdarzają się również sytuacje, gdy jakiś błąd powoduje pojawienie się kliku / kilkunastu wyjątków. Co więcej wyświetlane wyjątki mogą nie dotyczyć źródła problemu. Taki scenariusz stanowi idealne miejsce zastosowania opisywanej techniki.
Zacznijmy… Poniżej znajduje się obrazek przedstawiający sytuację, w której to nie można wyświetlić kontrolki w Visual Studio.
Jak można zauważyć nie udało się stworzyć instancji kontrolek BasicPasswordGenerator i AdvancePasswordGenerator. Dodatkową informacją jest to, że błąd ten jest spowodowany przez IsolateStorageException. Jeśli ktoś spotkał się wcześniej z taką sytuacją to jest prawie pewien, że kontrolka nie może zostać poprawnie wyświetlona ponieważ w którymś miejscu próbuje odczytać jakieś wartości z IsolateStorage. Odczyt taki możliwy jedynie na urządzaniu, bądź też emulatorze. W przypadku próby jego wykonania w Visual Studio otrzymamy wyjątek.
Jeśli natomiast ktoś nie wie gdzie występuje przyczyna błędu to może to wykorzystać drugą instancję Visual Studio. W drugiej instancji należy otworzyć ten sam projekt, w którym występuje błąd i podpiąć się do procesu pierwszej instancji Visual Studio (Debug -> Attatch to process…). Dla przypomnienie dodam, że proces Visual Studio nazywa się devenv.exe. Teraz pozostaje nam wybór sposobu działania:
- Breakpoint w miejscu podejrzanym – standardowe podejście do wyszukiwania błędów. Należy spróbować określić podejrzane miejsca i spróbować prześledzić działanie kodu. Najczęściej poszukiwania zaczyna się od konstruktora kontrolek.
- Pozwolenie na wykrycie miejsca w którym występuje wyjątek przez Visual Studio. Ponieważ wyjątek ten jest obsłużony to należy zmodyfikować ustawienia, aby Visual Studio zatrzymało się w miejscu wystąpienia wyjątku również obsłużonego. Robimy to poprzez zaznaczenie opcji Break when an exception is -> Common Language Runtime Exceptions -> Thrown w oknie Exceptions (menu Debug -> Exceptions…).
Po wybraniu sposobu działania pozostaje nam już tylko uruchomić w edytorze kontrolkę, która działa niepoprawiane i poszukać gdzie występuje błąd.
Z innych przykładów kiedy daną technikę można użyć to sytuacja, z którą miałem ostatnio do czynienie. Próbuję otworzyć kontrolkę, a w tym momencie Visual Studio się zamyka. Drugie Visual Studio zlokalizowało dokładnie linijkę, która powodowała błąd.
nie zdarzyło mi się jeszcze coś takiego, bym musiał z tego korzystać.. ale dobrze wiedzieć, że nawet takie problemy da się rozwiązać 🙂