Dlaczego w językach programowania błędy są nazywane „wyjątkami”, a nie „błędami”?

Właściwie o tym myślałem. Sam nie jestem rodzimym językiem angielskim, ale wciąż mam wieloletnie doświadczenie w programowaniu i zawsze o to pytałem. Dlaczego nazywa się wyjątek, ale nie jest błędem, ponieważ są błędami.

Może być PageNotFoundErrorzamiast PageNotFoundException.

Nie muszą wcale być błędami. Brak strony może być ciekawym faktem, a nie faktycznym błędem. Przyznaję, że niemal cały czas są wykorzystywane jako błędy. Ale czasami są one używane do przełamywania pętli lub informowania, że ​​łańcuch nie jest prawidłową liczbą. Można ich używać do przechowywania i zwracania ogromnej ilości przydatnych danych - w ramach dość normalnego zwrotu. (Niektóre języki są nieco powolne z wyjątkiem wyjątków, w takim przypadku częste ich rzucanie jest złym pomysłem.) Teoretycznie wyjątek oznacza po prostu „nie rób normalnego powrotu, idź na górę stosu wywołań, dopóki nie znajdziesz kogoś zainteresowanego w tym."

Nawet wyjątek wskaźnika zerowego może niewiele dla ciebie znaczyć. Wywołujesz kod innej osoby, a następnie wychwytujesz wyjątek wskaźnika zerowego, ponieważ wiesz, że może on wysadzić w powietrze, wydrukować komunikat z informacją, czyja to wina, i kontynuować pracę.

Mechanizm wyjątków nie zawsze jest wykorzystywany do sygnalizowania błędów. Wyjątki są zgłaszane poza zwykłymi sytuacjami, które wymagają oddzielnej ścieżki kodu do przetworzenia, w tym błędów. Na przykład użytkownik podający nazwę nieistniejącego pliku lub wprowadzający literę zamiast cyfry w polu numerycznym to wyjątkowe sytuacje wymagające specjalnej obsługi, ale nie są to błędy.

W niektórych środowiskach programowania, takich jak Java, dostępne są specjalne Errorobiekty do zgłaszania „prawdziwych błędów”, sytuacji, w których rozsądna aplikacja nie powinna podejmować prób. Obiekty te są dostarczane przy użyciu tego samego mechanizmu, który jest używany do dostarczania wyjątków, ale mają specjalne znaczenie sygnałów o sytuacjach niemożliwych do odzyskania.

Nie prowadzę badań etymologicznych na temat ich pochodzenia, ale rozumiem, że użycie terminu „Błąd” może nie być precyzyjne we wszystkich sytuacjach; również, jak wspomniano prawieSharepointMaster, lepiej pomyśleć o błędzie i wyjątku zgłoszonym jako oddzielne byty.

Kiedy jesteś w języku programowania wysokiego poziomu, sensownie jest zakładać, że wyjątek zawsze jest spowodowany błędem, chociaż zgadzam się również z dasblinkenlight, że nawet wtedy wyjątek nie zawsze jest konsekwencją błędu. Na przykład używam wyjątków do wspólnego kończenia wątków.

Po raz pierwszy zobaczyłem termin „wyjątek” w instrukcji montażu 80386. Pamiętam, że kiedy zobaczyłem, wyglądało to dla mnie naturalnie. Nazywanie tego błędem nie byłoby poprawne, ponieważ nie ma błędów w asemblerze; są po prostu warunki, z którymi procesor nie może sobie poradzić (jeśli jest to błąd - od programisty, użytkownika lub systemu - cóż, procesor jest całkowicie niezależny od tego). Nie wiem, czy Intel naprawdę powstał, czy nie, ale może ...

Powszechnie stosowany jest wyjątek do nazwania zdarzenia, które jest niepoprawne, ale można je odzyskać, jak out_of_rangewyjątek w C ++, który jest zgłaszany podczas uzyskiwania dostępu do elementu w wektorze lub tablicy, który nie istnieje. Oczywiście takie zdarzenie nie jest poprawne, ale zdarza się, że nie powinno to oznaczać awarii całego programu.

Z drugiej strony błędy są zwykle używane do nazwania czegoś, co powinno spowodować awarię wszystkiego, coś takiego jak przepełnienie stosu jest przykładem zdarzenia, które powinno zakończyć program, ponieważ program nie może go obsłużyć wewnętrznie. Innymi słowy: błąd jest poważny, a wyjątek stosunkowo niewielki.

Myślę, że ma to więcej wspólnego z „ewolucją” obsługi błędów. W przypadku języków C / C ++ (przed dodaniem obsługi wyjątków), jeśli funkcja się nie powiedzie, jedynym sposobem na to jest sprawdzenie wartości zwracanej (np. HRESULTW win32). Zwykle kończyło się to na łapaniu kodów wyjścia każdego wywołania funkcji i sprawdzaniu. Takie podejście sprawia, że ​​kod jest bardziej bałaganiarski. I wiele razy programiści unikają dodawania tych czeków z lenistwa.

Po wprowadzeniu obsługi wyjątków programiści mieli teraz dwie opcje zgłoszenia błędu. Tak więc słowo „wyjątek” zostało użyte do odróżnienia błędów od błędów „status wyjścia”. Po pewnym czasie obsługa wyjątków stała się popularnym sposobem propagowania błędów, ponieważ kod jest znacznie łatwiejszy do odczytania, utrzymania i może istnieć jedno miejsce, w którym można mieć logikę obsługi błędów.

W Pythonie są one nazywane ABCError Np .: KeyError, IndexError

http://docs.python.org/library/exceptions.html

Myślę więc, że to zależy od używanego języka.

Gdy wystąpi błąd, system lub aktualnie uruchomiona aplikacja zgłasza go, zgłaszając wyjątek zawierający informacje o błędzie. Po zgłoszeniu wyjątek jest obsługiwany przez aplikację lub domyślną procedurę obsługi wyjątków.

Błąd zgłasza wyjątek, który wyszczególnia błąd, więc nie wszystko jest błędem, który jest wyjątkiem, jeśli ma to sens;), na przykład niezamknięty wyjątek nie powinien być błędem, ale zgłasza wyjątek.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

W programowaniu na iOS / Mac mamy zarówno wyjątki, jak i błędy w jednym języku.

Przynajmniej w tym środowisku wyjątek jest „niemożliwy do odzyskania”, podczas gdy błąd jest „możliwy do odzyskania”.

Na przykład:

• jeśli masz tablicę z 10 elementami i próbujesz uzyskać dostęp do elementu o indeksie 30 - będzie to wyjątek. Popełniłeś błąd podczas programowania.
• jeśli spróbujesz pobrać adres URL, ale nie ma połączenia z Internetem, należy się tego spodziewać i powinieneś przekazać użytkownikowi jakąś wiadomość.

Wyjątki zwykle powodują awarię aplikacji, podczas gdy błędy zwykle zwracają się, nila obiekt błędu (zwracany jako parametr metody referencyjnej). Możesz wychwycić wyjątki za pomocą bloku try / catch / wreszcie, ale zaleca się, aby nigdy nie używać tej funkcji języka - jeśli możliwe jest odzyskanie wyjątku w jakikolwiek sposób, nie powinieneś w ogóle rzucać wyjątku (powinieneś powrócić obiekt błędu zamiast tego).

Błąd jest coś, co poszło źle w realizacji programu. Często rozwiązuje się to poprzez podniesienie wyjątku , ale

• nic nie zmusza programisty do obsługi błędu przez zgłoszenie wyjątku, oraz
• nic nie zmusza programisty do zgłaszania wyjątków tylko w przypadku błędu.

Błąd jest pojęciem semantycznym : jest stosowany przez programistę lub użytkownika, który przychodzi do programu z oczekiwaniami, aby opisać różnicę między ich oczekiwaniami a rzeczywistością. Tylko osoba może powiedzieć, czy procedura jest w stanie błędu, czy nie.

Wyjątek stanowi koncepcja składniowa : jest to coś w samym programie, niezależnie od oczekiwań kogokolwiek na temat tego, co ten program ma zrobić. Rutyna albo nie stwarza wyjątku, bez względu na to, co ktoś myśli.

Wyjątki i błędy są różne.

Wyjątkiem są sytuacje, które program może przezwyciężyć, na przykład próba otwarcia pliku i nie istnieje, podczas gdy błędy to sytuacje, w których program nie może nic zrobić, na przykład awaria dysku lub awaria pamięci RAM.

Zgłaszanie wyjątków i obsługa wyjątków to funkcje kontroli przepływu, a nazwa wyjątku powinna być zgodna z przeznaczeniem. Projektant kodu i interfejsu API powinien znaleźć dobre i spójne schematy nazewnictwa.

Odpowiedź na twoje pytanie brzmi: zależy to od kontekstu i perspektywy.

Wyjątki ewoluowały jako uogólnienie błędów. Pierwszy język programowania do włączenia mechanizmu wyjątków był Lisp na początku 1970 roku. Jest dobre podsumowanie w A Pattern of Language Evolution autorstwa Gabriela i Steele. Wyjątki (które nie były jeszcze nazywane wyjątkami) wynikały z potrzeby określenia zachowania programu w przypadku wystąpienia błędu. Jedną z możliwości jest zatrzymanie programu, ale nie zawsze jest to pomocne. Implementacje Lisp tradycyjnie miały sposób na wejście do debuggera w przypadku błędu, ale czasami programiści chcieli włączyć obsługę błędów w swoim programie. Tak więc implementacje Lisp z lat 60. XX wieku miały sposób powiedzieć „zrób to, a jeśli wystąpi błąd, zrób to zamiast tego”. Początkowo błędy pochodziły z prymitywnych funkcji, ale programiści uznali za celowe wyzwolenie błędu, aby pominąć część programu i przejść do procedury obsługi błędów.

W 1972 roku nowoczesna forma obsługi wyjątków w Lisp pojawiła się w MacLisp: throwi catch. Software Preservation Grupa wymienia wiele materiałów na wczesnych implementacjach Lisp, w tym The maclisp Reference Manual Wersja 0 Davida Księżyca . Prymitywy catchi throwsą opisane w §5.3 str.43.

catchto funkcja LISP do wykonywania ustrukturyzowanych wyjść nielokalnych. (catch x)ocenia xi zwraca swoje wartości, z wyjątkiem tego, że jeśli podczas oceny x (throw y)powinien zostać oceniony, catchnatychmiast wraca ybez dalszej oceny x.

catchmoże być również użyty z argumentem econd, bez oceny, który służy jako znacznik do rozróżnienia zagnieżdżonych połowów. (…)

throwjest używany catchjako ustrukturyzowany nielokalny mechanizm wyjścia.

(throw x)ocenia xi zwraca wartość z powrotem do najnowszej catch.

(throw x <tag>)zwraca wartość xpowrotu do najnowszego catchoznaczonego <tag>lub nieoznaczonego.

Nacisk kładziony jest na nielokalny przepływ kontroli. Jest to forma goto (goto tylko w górę), która jest również nazywana skokiem . Metafora jest taka, że ​​jedna część programu wyrzuca wartość, aby zwrócić ją do procedury obsługi wyjątków, a procedura obsługi wyjątków przechwytuje tę wartość i zwraca ją.

Obecnie większość języków programowania pakuje znacznik i wartość w obiekt wyjątku i łączy mechanizm przechwytywania z mechanizmem obsługi.

Wyjątki niekoniecznie są błędami. Są sposobem na wyjście z bloku kodu i otaczających go bloków, uciekając, dopóki nie zostanie osiągnięty moduł obsługi wyjątku. To, czy taka rzecz jest uważana za „błąd” w sensie intuicyjnym, jest subiektywne.

W niektórych językach rozróżnia się terminy „błąd” i „wyjątek”. Na przykład niektóre dialekty Lisp muszą zarówno throwzgłosić wyjątek (przepływ sterowania dla użytkowników, mający na celu wykonanie nielokalnego wyjścia w sposób, który nie oznacza, że ​​coś poszło „nie tak”), a signaltakże zgłoszenie błędu (co oznacza, że coś poszło „nie tak” i może spowodować zdarzenie debugowania).

Znajdziesz go różnie interpretowanego w różnych implementacjach języka programowania. Jak powiedział dasblinkenlight, jest to punkt widzenia java dotyczący rozgraniczenia błędu i wyjątku. W wielu językach programowania wyjątkami są naruszenia, które można obsłużyć lub zezwolić na propagację w celu przekazania do najwyższego możliwego modułu kodu. Błędy to na ogół sytuacje, w których kontener środowiska uruchomieniowego języka obsługuje (a wiele przypadków po prostu wstrzymuje wykonanie).

Błąd jest zawsze błędem. Wyjątkiem jest błąd w bieżącym kontekście. Oznacza to, że wyjątek jest wrażliwy na kontekst. Przykładem wyjątku byłoby dodanie ascii „a” do liczby całkowitej „1”. Błąd może przypominać użycie niezdefiniowanego operatora, takiego jak „+!” w większości języków.

Niektóre języki pozwolą Ci zdefiniować wyjście z sytuacji, jeśli naprawdę tego chcesz.