Kiedy zacząć pisać obsługę wyjątków, rejestrowanie

Kiedy zaczniesz pisać kod obsługi wyjątków? Kiedy zaczniesz pisać Oświadczenia rejestrujące.

Aby rozwinąć to pytanie, załóżmy, że jesteśmy na platformie .NET z logowaniem log4net, ale prosimy o ogólną odpowiedź.

Rozwiązanie: Projekt Windows Forms. Projekty: interfejs użytkownika, BusinessRules, DataHandlers

Czy więc zajmujesz się pisaniem swoich DataHandlerów, które najpierw wykonują twoje operacje na danych, takie jak Utwórz, Odczytaj, Aktualizuj, Usuń?

Następnie postępuj zgodnie z regułami biznesowymi

A potem twój interfejs użytkownika lub dowolna inna kombinacja powyższych.

Przetestuj swoją aplikację pod kątem funkcjonalności.

A potem zacznij pisać kod obsługi wyjątków i wreszcie kod logowania?

Kiedy jest właściwy moment, aby zacząć pisać kod obsługi wyjątków?

PS: W książce Clean Code mówią, że najpierw napisz blok try-catch-wreszcie . To skłoniło mnie do zadania tego pytania.

Kod obsługi wyjątków piszesz, gdy piszesz coś, co wywołuje coś, co może powodować wyjątki.

Na przykład, gdy piszesz coś, co wysyła dane do sieci, powinieneś także pisać kod, który obsługuje limity czasu połączenia. Wyjątek jest bezpośrednio związany z tym, co robisz, a praca jest świeżo w twoim umyśle.

Z drugiej strony, jeśli piszesz analizator składni, który zgłasza wyjątki, gdy napotka zniekształconą jednostkę danych protokołu, nie możesz napisać kodu obsługującego wyjątki dla wyjątków generowanych przez analizator składni . (Ale oczywiście piszesz testy, aby pokazać, jak i kiedy i dlaczego parser podnosi wyjątki!)

Powodem, dla którego sugerujesz, aby najpierw napisać próbę catch-catch, jest dwojaki: w końcu chodzi o oczyszczenie zasobów, które funkcja tworzy / zużywa, a napisanie catch to miłe przypomnienie, że wywoływane funkcje mogą zawieść, i musisz poradzić sobie (jeśli to konieczne) z tymi awariami.

Po fakcie staram się dodawać rejestrowanie. Nie jestem pewien, czy to mądre, ale właśnie to zadziałało dla mnie. Gdy zaczynam przeprowadzać testy akceptacyjne itp., I zaczynam problemy z trafieniem, a następnie dodam rejestrowanie, aby móc śledzić błędy. (A potem zostawiam logowanie.)

Z mojego doświadczenia wynika, że ​​jeśli nie napiszesz kodu z odpowiednią obsługą błędów i logowaniem od samego początku, nie da się tego zrobić z powodu presji czasu. Najbardziej udane prace programistyczne, na których się zacząłem, zaczynałem od określenia podstawowej struktury aplikacji, w tym standardu kodowania, sposobu obsługi błędów, logowania, podstawowej architektury i narzędzi testowych.

W przeciwnym razie okaże się, że masz zadania dla wersji 2.0, takie jak „Popraw obsługę błędów” i „Utwórz system rejestrowania”. Zostaną one wycięte na korzyść nowych funkcji, a ponieważ masz „zbyt wiele do zrobienia”, naprawianie wszystkich błędów w przypadkach błędów, o których nie pomyślałeś. (Co trwa wiecznie, ponieważ nie masz systemu rejestrowania.

Zależy od tego, co robisz

za wyjątkami:

Jeśli piszesz coś, co może zawierać błędy, lub coś, co ma dobre punkty najwyższego poziomu, aby pozwolić wyjątkom na pojawienie się ich w trakcie pisania.

Jeśli piszesz coś, co wymaga wydajności i ma małą możliwość wystąpienia błędów, brakuje sensownego miejsca na umieszczenie programów obsługi błędów, napisz programy obsługi błędów, w przypadku których testy dowodzą, że ich potrzebujesz.

W obu przypadkach, jeśli nie masz nic użytecznego do czynienia z błędem, zastanów się, czy nie może się to wydarzyć (bez procedury obsługi)

do logowania:

Jeśli potrzebujesz ścieżki audytu, musisz najpierw zapisać dane logowania. Jeśli zezwalasz na bąbelkowanie błędów aż do samej góry, musisz podać tam również rejestrowanie, aby dziennik mógł zostać przechwycony.

Oprócz tych przypadków, generalnie dodaję rejestrowanie tylko w miejscach, w których testowanie / użycie dowodzi, że jest to konieczne i zazwyczaj wybieram opcję skonfigurowania go po zakończeniu.

Możesz wdrożyć kontrolę i obsługę wyjątków jako usługi. Rejestrowanie kontroli na poziomie aplikacji wymaga danych o stanie każdej transakcji biznesowej. Możliwość monitorowania aplikacji w kontekście biznesowym lub transakcyjnym wymaga interfejsu monitorowania w ramach usługi do wysyłania komunikatów szczegółowo określających status transakcji specyficzny dla wywołania usługi. Wymaga to od każdej usługi wysłania komunikatu o stanie na krytycznych etapach transakcji biznesowej. Następnie można zbudować przeglądarkę w czasie rzeczywistym, aby skorelować komunikaty o stanie (w oparciu o semantykę komunikatu - np. Identyfikator transakcji) z usługami w aplikacji złożonej. Zapewnia to kompleksowy widok transakcji biznesowej w zakresie zarządzania umową SLA, śledzenia błędów i określania problemów.

Usługę audytu można następnie zaimplementować jako maszynę stanu, która może odbierać i rejestrować wiadomości na podstawie kryteriów określonych w jej konfiguracji. Ogólny moduł obsługi wyjątków może także używać usługi kontroli do obsługi scentralizowanego widoku problemów występujących w SOA przedsiębiorstwa - do obsługi monitorowania opartego na wyjątkach. Każdy warunek nie powinien występować w rozwiązaniu jest instrumentowany w celu wysłania komunikatu wyjątku do procedury obsługi wyjątku.

Napisz, kiedy będziesz go potrzebować, ale od samego początku projektuj, aby je uwzględnić.

Innymi słowy: spraw, aby istniał sposób obsługi tej możliwości rejestrowania, i dodaj rzeczywistą funkcjonalność nakrętek i śrub (jakie komunikaty rejestruje) później, gdy zajdzie taka potrzeba. W wyjątkach - dodaj haczyk (i wreszcie, jeśli go masz), zanim napiszesz rzut. Pomoże to uniknąć zapomnienia o jednym i oszczędzeniu sobie iteracji lub w najgorszym przypadku błędu / awarii.