Dlaczego nie użyć słowa błąd zamiast wyjątku? [Zamknięte]

Jeśli mówimy o wyjątkach jako błędach, dlaczego po prostu nie nazwać go błędem, a nie wyjątkiem?

Jeśli w kodzie nazywa się to wyjątkiem, a gdy tylko się pojawi, nazywa się to błędem. Dlaczego więc nie nazwać tego błędem?

Dziękujemy za odpowiedź lub komentarz.

Cóż, to całkiem proste: nie wszystkie wyjątki są błędami (i podobnie, nie wszystkie błędy objawiają się jako wyjątki).

Jako przykład wyjątku, który nie jest błędem, jeśli czytasz plik z dysku USB i ktoś wyciąga dysk z gniazda. To spowoduje powstanie wyjątku (to znaczy w większości języków, które obsługują wyjątki). Ale to nie jest błąd w kodzie.

I odwrotnie, błąd może objawiać się jako błąd obliczeniowy lub coś w tym rodzaju. Nadal dostajesz odpowiedź, to po prostu nie jest właściwa.

To powiedziawszy, wyjątek, który dociera aż do szczytu stosu, prawdopodobnie jest błędem. W powyższym przykładzie USB powinieneś być w stanie wychwycić ten wyjątek i przedstawić użytkownikowi miły błąd z informacją: „Nie można odczytać z pliku, ponieważ nie jest on już podłączony”. lub coś. Jeśli po prostu podasz im IOExceptionjakiś funky kod błędu, to jest to błąd. Ale sam wyjątek nie jest.

Prosty i prosty, wyjątek nie jest (zawsze) błędem!

Zgłaszany jest wyjątek (lub powinien być), gdy dzieje się coś wyjątkowego. Jeśli występuje problem z moim dyskiem twardym i nie można zapisać pliku, nie jest to błąd. To jest awaria sprzętu.

Błąd jest zazwyczaj wynikiem złego programowania. Jeśli aplikacja robi coś, czego nie oczekuje się w wyniku błędu programowania, jest to błąd.

To nie to samo.

Bug jest niezamierzone zachowanie kawałek oprogramowania: oprogramowanie nie robi to, co ma robić. Błędy mogą występować na wszystkich poziomach rozwoju oprogramowania, od zwykłych starych literówek, przez błędy logiczne, aż po nieodpowiednie specyfikacje funkcjonalne.

Wyjątkiem , przeciwnie, może odnosić się albo niezwykłego stanu programu, odbiegające od normalnego stanu, lub, bardziej szczegółowo, do konstrukcji języka, w którym sygnał i obsługiwać takie warunki.

Wystąpienie wyjątku może być oznaką błędu, ale często tak nie jest. Na przykład aplikacja, która ma pobrać dokument z adresu URL i przetworzyć go lokalnie, może zgłosić wyjątek, gdy zdalny serwer jest wyłączony: aplikacja odbiega od normalnego działania (nie może pobrać i przetworzyć dokumentu), ale jeśli odpowiednio obsługuje wyjątek i odzyskuje, wtedy nie ma błędu.

I odwrotnie, obecność błędu niekoniecznie objawia się jako wyjątek. Aplikacja może po cichu odrzucić wprowadzone dane, zamiast przechowywać je w swojej bazie danych; nie zostanie zgłoszony żaden wyjątek, ale nadal jest to błąd.

Wyjątki i błędy nie są w ogóle powiązane. Jasne, czasami rzucasz wyjątek i to oznacza błąd. Ale czasami oznacza to po prostu wyjątkową, niezwykłą okoliczność, która niekoniecznie jest błędem w programie. Zwłaszcza w języku zadowolonym z wyjątków, takim jak Java, gdzie każda standardowa operacja i jej pies rzuca około pięciu różnych wyjątków - na przykład niepowodzenie otwierania pliku, niepowodzenie odczytu pliku itp.

Wyjątki nie zawsze są związane z błędami. Pomyśl o tym jako o czymś, co może pójść nie tak z tym, co robisz.

Przykładem, który przychodzi mi na myśl, jest InetAddress.getByName (), która służy do rozpoznawania nazwy domeny. Jeśli coś się stanie i zostanie zgłoszony wyjątek UnknownHostException, to tak naprawdę nie jest to problem z kodem.

Błąd oprogramowania jest powszechnym terminem używanym do opisania błędu, wady, pomyłki, awarii lub błędu w programie komputerowym lub systemie, który daje niepoprawny lub nieoczekiwany wynik lub powoduje, że zachowuje się w niezamierzony sposób. Może nawet jest to błąd pisowni na etykiecie.

Wyjątki różnią się od błędów. Każdy rodzaj wyjątku (naruszenie dostępu, przepełnienie stosu itp.) Może zostać zgłoszony do debuggera jako wyjątek „pierwszej szansy” lub „drugiej szansy”. Wyjątki od pierwszej szansy z definicji nie mają charakteru krytycznego, chyba że nie są odpowiednio obsługiwane za pomocą procedury obsługi błędów, w którym to momencie są one zgłaszane ponownie jako wyjątek od drugiej szansy (który może obsłużyć tylko debugger).

Jeśli żaden debugger nie obsługuje wyjątku drugiej szansy, aplikacja zostaje zamknięta.

Możesz sam uzasadnić wyjątek, miejmy nadzieję, że celowo nigdy nie wprowadzisz błędu.

Wszystkie wyjątki nie są błędami. Tematem debaty może być to, że wszystkie błędy są wyjątkami, czy nie.

Możemy powiedzieć, że wyjątkami są zdarzenia, które nie są częścią normalnego lub oczekiwanego przepływu aplikacji. Zdarzenia te mogą być niezależne od sposobu pisania kodu, gdzie błąd jest zasadniczo wynikiem złego kodu (np. Złego obliczenia).

Oto przykład, jak brak obsługi wyjątku może być błędem.

Załóżmy, że istnieje program, który zapisuje niektóre dane na zewnętrznym urządzeniu magazynującym. Podczas pisania zewnętrzne urządzenie pamięci masowej było odłączone od zasilania, uległo awarii lub może zostać zniszczone (z jakiegokolwiek powodu). Jest to wyjątkowy przypadek, niezależnie od tego, czy język programowania obsługuje wyjątkową obsługę, czy nie, jeśli program ulegnie awarii lub zachowa się z powodu tego zdarzenia, jest to błąd (użytkownik końcowy może nie wiedzieć, co się stało. Jest to również bardzo nieprzyjemne) . Ale jeśli program przerywa proces z wdziękiem, powiadom użytkownika (innymi słowy obsługuj wyjątek), to oczywiście nie jest błąd.

Języki programowania try catch machanism są zasadniczo narzędziem ułatwiającym nam wyjście z nieoczekiwanych zdarzeń.

Streszczenie : Wyjątki są dowodem złych wyników, błędy są (niektóre z) przyczyn złych wyników. Problem (do rozwiązania) nie jest wyjątkiem, problemem jest to, co spowodowało wyjątek.

Resoning: bug jest defekt w projektowaniu lub realizacji wyrobu (nie ograniczając się do oprogramowania). Na przykład, niestosowanie odpowiednio oszacowanego przekaźnika (czas / czułość / niezawodność / pojemność) z powodu nieprawidłowej specyfikacji lub prostego błędu kompilacji. Wyjątkiem jest prawdziwy świat / run odchylenie od czasu przewidzieć (ośmielę się powiedzieć, „oczekiwać”?) Zachowań, na przykład utraty kontroli nad pojazdem podczas jazdy.

Oczywiście błąd może powodować wyjątek, ponieważ przykład w 1) może prowadzić do przykładu w 2). Ale nie wszystkie wyjątki byłyby spowodowane błędami, np. Utratą kontroli nad pojazdem, ponieważ operator miał udar.

Ponieważ pytanie to zostało ponownie otwarte na nagrodę, pozwól mi wspomnieć o moim artykule CUJ z 2003 roku zatytułowanym „Wyjątek czy błąd?”, Który wydaje się odpowiadać dokładnie na pytanie OP.

Zasadniczo w artykule zdefiniowano pojęcia „błąd” i „wyjątek” (podając przykłady) oraz zaproponowano strategie radzenia sobie z każdym z nich.

W artykule zaproponowano, aby nie „obsługiwać” błędów, ale zamiast tego oflagować je za pomocą asercji. Natomiast prawdziwe wyjątki wymagają obsługi kodu (możliwe zgłaszanie wyjątków / wyłapywanie).

Najważniejsze jest to, że błędy wymagają dokładnie przeciwnej strategii niż wyjątki.

Wyżej wymieniony artykuł jest już dostępny w Dr.Dobb's pod adresem : http://www.drdobbs.com/an-exception-or-a-bug/184401686