Używasz asercji zamiast rzucać wyjątkami?

Często, gdy piszę funkcje, chcę się upewnić, że dane wejściowe są prawidłowe, aby wykryć takie błędy jak najwcześniej (uważam, że są to tak zwane warunki wstępne). Kiedy warunek wstępny zawiedzie, zawsze rzucałem wyjątek. Ale zaczynam wątpić, czy jest to najlepsza praktyka, a jeśli nie, twierdzenia byłyby bardziej odpowiednie.

Więc kiedy mam to zrobić: kiedy należy zastosować stwierdzenie, a kiedy należy zgłosić wyjątek?

Asercji należy używać wyłącznie do weryfikacji warunków, które z logicznego punktu widzenia nie mogą być fałszywe (czytaj: sprawdzanie rozsądku). Warunki te powinny opierać się wyłącznie na danych wejściowych wygenerowanych przez własny kod. Wszelkie kontrole oparte na danych zewnętrznych powinny wykorzystywać wyjątki.

Prostą zasadą, którą zwykle stosuję, jest weryfikowanie argumentów funkcji prywatnych za pomocą asercji i stosowanie wyjątków dla argumentów funkcji publicznych / chronionych.

Asercje służą do znajdowania błędów programistycznych. Twoje programy muszą działać równie dobrze, gdy wszystkie twierdzenia zostaną usunięte.

Z drugiej strony wyjątki dotyczą sytuacji, które mogą się zdarzyć nawet wtedy, gdy program jest doskonały; są spowodowane wpływami zewnętrznymi, takimi jak sprzęt, sieć, użytkownicy itp.

Typową praktyką programistyczną jest kompilowanie asercji z kompilacji produkcyjnych / wydania. Asercje pomogą tylko podczas testów wewnętrznych, aby uchwycić niepowodzenie założeń. Nie powinieneś zakładać zachowania zewnętrznych agencji, więc nie powinieneś twierdzić o zdarzeniach z sieci lub użytkownika. Dobrą praktyką jest również pisanie kodu obsługi kompilacji produkcyjnych w przypadku niepowodzenia asercji.

Na przykład w C

int printf(const char *fmt, ...)
{
  assert(fmt);  // may fail in debug build but not in production build
  if (!fmt) return -1; // handle gracefully in production build
  ...
}

Wyjątki mają być wbudowane w kompilacje produkcyjne. Alternatywą dla wyjątku jest zwracanie błędu, a nie asercji.

Jednym z problemów z twierdzeniami jest dla mnie to, że są one domyślnie wyłączone w Javie.

Stosujemy strategię pierwszego niepowodzenia, w której program - który mógł działać przez lata bez nadzoru - musi ulec awarii tak wcześnie, jak to możliwe, aby uniknąć uszkodzenia danych w przypadku złych danych (w nieoczekiwanej formie). Do tego używamy sprawdzania, a używając zapewnień, w zasadzie ryzykujemy, że nie będą aktywne.