Korzyści z asertywnego programowania

Question

Jaki jest sens włożenia praw do naszego kodu? Jakie są zalety asertywnego programowania?

private void WriteMessage(string message) 
{ 
    Debug.Assert(message != null, "message is null"); 

    File.WriteAllText(FILE_PATH, message); 
} 

Na przykład możemy sprawdzić zmienną komunikatu i podać tutaj wyjątek. Dlaczego używam tutaj asert? A może jest to zły przykład, aby zobaczyć korzyści z twierdzeń?

Answer 1

Wspierają także filozofię niepowodzenia, wyjaśnione w this article przez Jima Shore'a.

Answer 2

Jeśli jest określony warunek wstępny dla metody pobrania parametru o wartości niepustej, to program ma być FAIL, gdy tylko warunek wstępny nie zostanie spełniony, a źródło błędu musi wówczas byc naprawionym.

Uważam, że asercje są ważniejsze przy opracowywaniu oprogramowania o znaczeniu krytycznym dla bezpieczeństwa. I na pewno wolisz używać twierdzeń, gdy oprogramowanie zostało formalnie określone.

Answer 3

Aby uzyskać doskonałą dyskusję na temat twierdzeń (i wielu innych tematów związanych z konstrukcją kodu), sprawdź numer Code Complete Steve McConnel. Cały rozdział poświęca efektywnemu wykorzystaniu twierdzeń.

Answer 4

Używam ich do sprawdzenia, czy dostałem ważną klasę zależną. dla przykładu w konstruktorze DI zazwyczaj akceptujesz jakąś zewnętrzną klasę, na której jesteś zależny, aby zapewnić jakieś działanie lub usługę.

dzięki czemu można stwierdzić (classRef! - null, "classRef nie może być pusta"); zamiast czekania na przekazanie wiadomości do klasy ClassRef i uzyskanie innego wyjątku, na przykład wyjątku: naruszenia zasad dostępu lub czegoś równie niejednoznacznego, które może nie być natychmiastowe z patrzenia na kod.

Answer 5

Ważnym rozróżnieniem, jakie należy wziąć pod uwagę, są rodzaje błędów, które chciałbyś złapać za pomocą asercji. Często używam asercji do przechwytywania błędów programowania (tj. Wywoływania metody z parametrem zerowym) i innego mechanizmu obsługi błędów walidacji (np. Podania numeru ubezpieczenia społecznego o niewłaściwej długości). Aby błąd programowania został złapany przy pomocy asercji, chcę szybko zawieść. W przypadku błędu sprawdzania poprawności chcę odpowiedzieć mniej drastycznie, ponieważ może być normalne, że wystąpiły błędy w danych (np. Użytkownik dokonał pewnego rodzaju wprowadzania danych). W takich przypadkach właściwym postępowaniem może być zgłoszenie błędu użytkownikowi i dalsze funkcjonowanie.

Answer 6

Gdzie niektórzy ludzie piszą:

/* 
* This can never happen 
*/ 

jej znacznie bardziej praktyczne napisać:

assert(i != -1); 

Lubię użyciu twierdzi, ponieważ są one łatwo wyłączone z prostego czasie kompilacji stała lub wykonane zrobić coś innego, jak przygotować raport o błędzie. Zazwyczaj nie włączam asercji (przynajmniej nie w zwykły sposób) podczas uwalniania czegoś.

Używanie ich uratowało mnie od robienia bardzo głupich błędów na komputerach innych ludzi .. tych odważnych dusz, które lubią testować mój kod alfa. Korzystanie z nich oraz narzędzi takich jak valgrind pomaga zagwarantować, że złapię coś strasznego przed popełnieniem.

Answer 7

Bardzo przydatne jest przetestowanie naszych założeń. Zapewniamy, że stale upewniamy się, że niezmiennik jest prawdziwy.W skrócie jest on stosowany w następujących celach,

• Pozwala to realizować system fail-fast.
• To zmniejsza propagację błędu z powodu efektów ubocznych.
• Zabrania to (rodzaj testu poprawności) systemu do wejścia w niespójny stan z powodu danych użytkownika lub kolejnych zmian kodu.

Czasami preferuję użycie assert_return(), gdy nie chcemy używać metody try/catch/throw.

private void WriteMessage(string message) 
{ 
    assert_return(message != null, "message is null"); // return when false 
    File.WriteAllText(FILE_PATH, message); 
} 

Proponuję assert_return(), aby zatrzymać aplikację, zgłaszając błąd w kompilacji testowej. A następnie w systemie produkcyjnym, powinien on zalogować się i błąd i powrócić z funkcji, mówiąc, że nie może tego zrobić.