Debugowanie.Assert vs Exceptions

Po pierwsze, Ważność MyClass powinna być oczywiście wyrażona przez niezmiennik MyClass .

Po Drugie, mówisz "oczekujemy, że MyMode będzie aktualizowany przez zewnętrznych użytkowników tej klasy" - oczywiście setter tego trybu powinien mieć typową formę design-by-contract (jak każda publiczna Funkcja):

  void Setter(mode m)
  {
    // INVARIANT ASSERT (1)
    // PRECONDITION ASSERTS (uses "m") (2)

    // BODY (3)

    // POSTCONDITION ASSERTS (if any) (4)
    // INVARIANT ASSERT (5)
  }

W (5) nie powiodłoby się z krzyczącym twierdzeniem, którego niezmiennik nie trzyma. ale w (2) wcześniej by Ci się nie udało, ponieważ tryb M przekazany jest nieważne. to wyśle jasny komunikat do użytkownika i w ten sposób rozwiąże twój problem.

I proszę mi nie mówić, że pole mode jest publiczne i użytkownicy zmieniają je bez żadnej kontroli.

Edit: o twierdzeniach i trybie wydania Zobacz też:

• Czy twierdzenia zawsze są złe?

• Kiedy powinny pozostać w kodzie produkcyjnym?

• Projekt według umowy z wykorzystaniem twierdzeń lub wyjątki?

Zasadniczo zgadzam się z konkluzją twojego pytania: Jeśli AKod wszy wykryje błąd A wszy popełnione, jest to przypadek Assert (a twierdzenia powinny być pozostawione w kodzie produkcyjnym, chyba że wydajność nakazuje inaczej). Jeśli kod Alicji wykryje błąd w kodzie Eve, jest to przypadek dla Exceptions, zakładając, że Alicja i Ewa znajdują się po przeciwnych stronach Twojego oprogramowania do śledzenia błędów.

To jest ogólna zasada. Twierdzenia, w nieco zmodyfikowanej formie, mogą być również używane jako " heads-up, developer!" mechanizm (i wtedy nie powinny być nazywane "ASSERT", ale "HEADS_UP" lub coś podobnego). Co zrobić, jeśli Twoja firma opracowuje produkt klient / serwer, a serwer wyśle nieprawidłowe dane do klienta? Jeśli jesteś programistą klienta, masz ochotę traktować go jako dane zewnętrzne (To dane Eve są kaputtem) i chcesz rzucić wyjątek. Ale" łagodniejsze " twierdzenie, które sprawia, że Visual Studio zatrzymanie debuggera może być bardzo dobrym sposobem na wczesne wykrycie tych problemów i zgłoszenie ich zespołowi serwera. W prawdziwej Instalacji Może to być Mallory temperowanie danych między Eve i Alice, ale w większości przypadków jest to błąd jednego z twoich kolegów i chcesz go zobaczyć, kiedy to się stanie - dlatego nazywam je twierdzeniami "heads-up": nie zastępują wyjątków, ale dają Ostrzeżenie i szansę na sprawdzenie problemu.

Często oba: Assert, throw.

Twierdzisz, ponieważ chcesz powiadomić deweloperów o błędnym założeniu podczas rozwoju.

Rzucasz, ponieważ jeśli dzieje się tak w release build, musisz upewnić się, że system nie kontynuuje przetwarzania, gdy jest w złym stanie.

Pożądana charakterystyka niezawodności Twojego systemu może mieć wpływ na twój wybór tutaj, ale "assert then throw" jest często użyteczną strategią, myślę.

Moje zastosowanie wynika z pomysłów z design by contract. Zasadniczo zapewniasz, że przychodzące parametry, zmienne globals i inne informacje o stanie są ważne podczas wprowadzania funkcji, a zwracane wartości i stan są również ważne podczas opuszczania. Jeśli na początku pojawi się błąd w kodzie wywołującym, jeśli na końcu pojawi się błąd w tym kodzie. Są to warunki wstępne i warunki post.

Twierdzenie w instrukcji switch jest tylko bardzo przydatne, jeśli sprawdziłeś swoje warunki wstępne przy wejściu. Jeśli w tym scenariuszu osiągniesz stan nieakceptowalny w środku swojej funkcji, jest to awaria funkcji lub funkcja wywołana. Osobiście trzymałbym się tu twierdzenia, ponieważ nie jest to wyjątek. Jak sugerujesz, wyjątki dotyczą zasobów, a nie błędów. Możesz jednak utworzyć niestandardowy moduł obsługi twierdzeń, który istnieje w kompilacji release i rzuca wyjątek w przypadku niepowodzenia, aby nadać programowi możliwość powrotu do stabilnego stanu.

Powiedziałbym: użyj wyjątku, jeśli błąd znajduje się w cudzym kodzie lub w kodzie w innym podsystemie (niezależnie od tego, czy go napisałeś, czy nie). Użyj również wyjątku, jeśli w danych pochodzących z zewnętrznego źródła, takiego jak plik, wystąpił błąd.

Czasami nie wiadomo, czy dane pochodzą z zewnętrznego źródła, czy nie. Jeśli Bezpieczeństwo jest ważne i istnieje możliwość, że masz do czynienia z danymi zewnętrznymi, które nie zostały zweryfikowane prawidłowo, użyj wyjątku. Jeśli bezpieczeństwo nie jest ważne wtedy użyłbym wydajności jako tiebreakera: czy ten kod może być wykonywany w ciasnej pętli? Jeśli tak, rozważ użycie assert, ponieważ uzyskasz lepszą wydajność w kompilacji Release. W przeciwnym razie użyj wyjątku.

To zależy od języka, jest to jednak w Javie twierdzenia muszą być włączone, aby to działało, więc wyjątek jest lepszy. Jednak zawsze lepiej mieć konkretny wyjątek, więc tutaj powinno być Nielegalstateexception.

W. Net, metody klas Debug nie są zawarte w programie, gdy tworzysz release build, więc będziesz musiał rzucić wyjątek, jeśli ten kod trafi do produkcji.