Niespodziewane wyjście poza zakres

Tło

Dziś czy wczoraj (niedawno w każdym razie) natknęliśmy się na ciekawy błąd. Otóż nasz sterownik zaczął się wyłączać. Sam z siebie, po jakimś czasie po prostu był zamykany, po czym rodzaj Watchdoga uruchamiał go ponownie. Podziałał troszkę i znów koniec. Nic w logach nie było (a logów mamy mnóstwo – pisałem kiedyś, jak są one potrzebne na produkcji) i moglibyśmy się długo zastanawiać nad przyczynami, gdyby nie fakt, że akurat mogliśmy sprawdzić działanie modułu krok po kroku lokalnie za pomocą VisualStudio. Po jego uruchomieniu ujrzeliśmy bardzo ciekawe rezultaty, o których niżej 🙂

Rozwiązanie zagadki

Problematyczny kod został przedstawiony poniżej. Jak widać, to zwykła wykonująca swoje zadania opakowane w blok try/catch/finally. Po zakończeniu przebudowy topologii, czeka zadaną ilość minut i podejmuje zadanie ponownie.

Po zdebugowaniu okazało się, że problem pojawił się w jedynej linijce z bloku finally. Otóż rzucany tam był wyjątek:

Wyszliśmy poza zakres i to nigdzie indziej, jak w bloku finally. Niemiły zbieg okoliczności. A wszystko to ponieważ parametr konfiguracyjny TopologyUpdateIntervalInMinutes został ustawiony na bardzo dużą liczbę (w celach poznawczych – aby zmiany w topologii nie zachodziły zbyt często). Rzucający wyjątek kod znajduje się w metodzie WaitOne:

Nie ma czego omawiać – metoda rzuca wyjątek, gdy ustawimy zbyt długi czas oczekiwania. Nie miało to żadnego wpływu w normalnych warunkach pracy, ale połączenie zbyt wysokiej testowej wartości parametru tego, że wyjątek był rzucany w bloku finally, a także faktu, że cała metoda była przekazywana do Tasku jako parametr spowodowało, że nic nie widzieliśmy w logach, a aplikacja po prostu wyłączała się.

Powyżej kod wołający naszą metodę. Gdy wyjątek był rzucany i nie łapany w środku powinniśmy sprawdzić jego właściwość IsFaulted i/lub Exception, aby zakomunikować światu, że stało się coś niedobrego. Ot, człowiek uczy się całe życie.