Błąd ukrywania
W programowaniu komputerowym ukrywanie błędów (lub połykanie błędów ) to praktyka polegająca na wychwytywaniu błędu lub wyjątku , a następnie kontynuowaniu bez rejestrowania, przetwarzania lub zgłaszania błędu do innych części oprogramowania. Obsługa błędów w ten sposób jest uważana za złą praktykę i antywzorzec w programowaniu komputerowym . W językach obsługujących obsługę wyjątków praktyka ta nazywana jest połykaniem wyjątków .
Błędy i wyjątki mają kilka celów:
- Pomóż opiekunom oprogramowania wyśledzić i zrozumieć problemy, które występują, gdy użytkownik uruchamia oprogramowanie, w połączeniu z systemem rejestrowania
- dostarczać użytecznych informacji użytkownikowi oprogramowania w połączeniu z istotnymi komunikatami o błędach, kodami błędów lub typami błędów wyświetlanymi w interfejsie użytkownika, jako komunikaty konsoli lub jako dane zwracane z interfejsu API (w zależności od typu oprogramowania i typu użytkownika)
- Wskaż, że normalne działanie nie może być kontynuowane, aby oprogramowanie mogło cofnąć się do alternatywnych sposobów wykonania wymaganego zadania lub przerwać operację.
Gdy błędy zostaną połknięte, cele te nie mogą zostać osiągnięte. Informacje o błędzie są tracone, co bardzo utrudnia śledzenie problemów. W zależności od tego, jak oprogramowanie jest zaimplementowane, może powodować niezamierzone skutki uboczne, które przeradzają się w inne błędy, destabilizując system. Bez informacji o pierwotnej przyczynie problemu bardzo trudno jest ustalić, co jest nie tak lub jak to naprawić.
Przykłady
Języki z obsługą wyjątków
W tym przykładzie C# , mimo że kod wewnątrz bloku try zgłasza wyjątek, zostaje przechwycony przez klauzulę blanket catch . Wyjątek został pominięty i jest uważany za obsłużony, a program jest kontynuowany.
spróbuj { wyrzuć nowy wyjątek (); } złap { // nic nie rób }
W tym przykładzie programu PowerShell klauzula trap przechwytuje zgłaszany wyjątek i połyka go, kontynuując wykonywanie. Komunikat „Nie powinno mnie tu być” jest wyświetlany tak, jakby nie zdarzył się żaden wyjątek.
&{ trap { kontynuuj } throw write-output "Nie powinno mnie tu być" }
Połykanie wyjątków może się również zdarzyć, jeśli wyjątek zostanie obsłużony i ponownie zgłoszony jako inny wyjątek, odrzucając oryginalny wyjątek i cały jego kontekst.
W tym przykładzie C# wszystkie wyjątki są przechwytywane niezależnie od typu i zgłaszany jest nowy wyjątek ogólny, zachowujący tylko komunikat oryginalnego wyjątku. Oryginalny ślad stosu zostaje utracony wraz z typem oryginalnego wyjątku, wszelkimi wyjątkami, dla których oryginalny wyjątek był opakowaniem, oraz wszelkimi innymi informacjami przechwyconymi w obiekcie wyjątku.
try { // zrób coś } catch ( Exception ex ) { // może zrób lokalną obsługę wyjątku throw new Exception ( np . Message ); }
Lepszym sposobem ponownego zgłaszania wyjątków bez utraty informacji jest zgłoszenie oryginalnego wyjątku z klauzuli catch :
try { // zrób coś } catch ( wyjątek ex ) { // wykonaj lokalną obsługę zgłoszenia wyjątku ; }
Alternatywnie można utworzyć nowy wyjątek, który zawija oryginalny wyjątek, więc wszystkie inne moduły obsługi będą miały dostęp do obu:
try { // zrób coś } catch ( Exception ex ) { // może zrób lokalną obsługę wyjątku throw new CustomException ( ex ); }
Inne języki
W Go błędy są propagowane przez zwrócenie obiektu Error wraz z normalną wartością zwracaną przez funkcję. Można to zignorować, jak w tym przykładzie.
f , _ := „Nie powinno mnie tu być” , błędy . Nowy ( "" ) fmt . Drukuj ( f )
W przypadku wywołań systemowych C błędy są wskazywane przez zwracaną wartość wywołania NULL , a informacja o błędzie jest przechowywana w globalnej zmiennej errno . Ten kod upewnia się, że plik jest ważny przed uzyskaniem do niego dostępu, ale jeśli fopen się nie powiedzie, błąd zostanie połknięty.
PLIK * plik = fopen ( "" , "r" ); if ( plik ) { // zrób coś z plikiem }
Powoduje
Najczęstszą podstawową przyczyną połykania błędów jest brak dobrych narzędzi i procesów rejestrowania podczas tworzenia oprogramowania przez programistę. W obliczu błędu, którego nie można łatwo obsłużyć, jeśli programista ma dobre narzędzia do rejestrowania, rejestrowanie nieoczekiwanego błędu nie kosztuje programisty czasu ani wysiłku. Logowanie błędu powinno być proste (jedno wywołanie metody), szybkie (bez wpływu na wydajność aplikacji), bezpieczne (nie generuje żadnych błędów ani wyjątków) oraz zapewnia zapisanie wszystkich informacji poprzez rejestrację rodzaju błędu i wszelkich istotnych powiązane z nim dane, ślad stosu błędu (aby programista mógł dokładnie określić, gdzie wystąpił błąd i jakie instrukcje do niego doprowadziły) oraz znacznik czasu błędu.
Tymczasowe procedury obsługi wyjątków
W językach ze sprawdzonymi wyjątkami wszystkie wyjątki zgłaszane w metodzie muszą być wymienione w sygnaturze tej metody. Podczas tworzenia prototypów i wdrażania oprogramowania kod często się zmienia, co oznacza, że typ wyjątków, które mogą zostać zgłoszone w metodzie, również często się zmienia. Konieczność dostosowywania sygnatury metody za każdym razem, gdy coś się zmienia, spowalnia rozwój i może być frustrująca, dlatego połykanie wyjątków jako środka tymczasowego podczas wprowadzania dużych zmian w kodzie jest atrakcyjne. Ten tymczasowy kod obsługi wyjątków może znaleźć się w zwolnionej bazie kodu.
Nawet w językach bez sprawdzonych wyjątków może się zdarzyć dodanie tymczasowej obsługi wyjątków podczas dużych zmian w kodzie w celu przyspieszenia prototypowania, co może prowadzić do połykania błędów.
Zapobieganie awariom
W sytuacjach, w których oprogramowanie nie może ulec awarii z jakiegokolwiek powodu, połykanie błędów jest praktyką, w którą programista może łatwo wpaść. Na przykład oczekuje się, że wtyczka działająca w innej aplikacji będzie obsługiwać wszystkie błędy i wyjątki w taki sposób, aby nie powodować awarii aplikacji, w której jest osadzona. Zbiorcze wychwytywanie błędów i wyjątków to wzorzec, w który łatwo wpaść, próbując za wszelką cenę zapobiegać awariom, a kiedy połączysz to ze słabymi narzędziami do rejestrowania, może się zdarzyć połykanie błędów.
Ukrywanie złożoności przed użytkownikami
Podczas pokazywania użytkownikom błędów ważne jest, aby przekształcić tajemnicze błędy techniczne w komunikaty wyjaśniające, co się stało i jakie działania użytkownik może podjąć, jeśli w ogóle, aby rozwiązać problem. Podczas wykonywania tego tłumaczenia błędów technicznych na zrozumiałe komunikaty dla użytkownika, określone błędy są często grupowane w bardziej ogólne błędy, a proces ten może prowadzić do tego, że komunikaty użytkownika staną się tak bezużyteczne, że użytkownik nie będzie wiedział, co poszło nie tak ani jak to naprawić. Jeśli chodzi o użytkownika, błąd został połknięty.
Zobacz też
- ^ „Najlepsze praktyki IBM: przechwytywanie i ponowne zgłaszanie wyjątków Java” . www-01.ibm.com . 2009-06-24 . Źródło 2019-05-02 .