Czy w zasadzie istnieją wyjątki, aby zapobiec awarii systemu?

Po drugie, zastanawiałem się, czy ktoś wiedział, jaka jest różnica między wyjątkami (w dziedzinie przepływu kontroli wyjątków) a wyjątkami (takimi jak używane w Javie).

Ale czy mają one zasadniczo chronić system przed awarią poprzez zakończenie programu użytkownika?

Istnieją wyjątki , które umożliwiają obsługę wyjątków , co pozwala uniknąć awarii, ale bardziej ogólnie zapobiega niepożądanemu lub nieprzewidywalnemu działaniu systemu. Na przykład, jeśli mój program łączy się z bazą danych, limit czasu zwykle nie powoduje awarii systemu, ale jeśli zależałem od danych z bazy danych, wyjątek może pozwolić mi potraktować tę sytuację bez danych inaczej niż normalnie.

Powiedz domyślnie, że mój program wyświetla stronę danych na podstawie tego, co zostało zwrócone z bazy danych - no cóż, nie mam danych. Zamiast przedstawiać pomieszany widok lub kontynuować potencjalnie niepoprawną operację, mogę złapać ten wyjątek i wrócić do innej bazy danych, odczytać dane lokalne, poprosić użytkownika o dane lub w inny sposób przywrócić użytkownika lub system do bezpiecznego stanu (prawdopodobnie jednego nie spowoduje to od razu tego samego wyjątku!)

Ponadto w systemach, w których wkład użytkownika może być przyczyną / rozwiązaniem problemu, wyjątki mogą dać użytkownikowi szczegółowe i pomocne informacje na temat problemu. Zamiast zbyt częstego „Wystąpił nieobsługiwany wyjątek w ...” lub „Zastraszający komunikat o błędzie prosto z SQL” możesz powiedzieć użytkownikowi coś pomocnego lub co najmniej zrozumiałego, np. „Nie można połączyć się z zasobem B.”

Wyjątki zostały stworzone w celu uproszczenia obsługi błędów. Bez wyjątków logika obsługi błędów musi być rozłożona na aplikacje. Każda funkcja, która może spowodować błąd, musi w jakiś sposób zwrócić status błędu, a po każdym wywołaniu musi zostać sprawdzony błąd. Często osoba dzwoniąca nie może zrobić nic użytecznego w przypadku błędu i może sama zwrócić błąd. Połowa kodu aplikacji może być poświęcona obsłudze błędów. Taki kod jest wyjątkowo delikatny. Zbyt łatwo jest pominąć kontrolę błędów i spowodować awarię lub, co gorsza, zwrócić nieprawidłowe wyniki z powodu niezauważonego błędu.

Z wyjątkami błędy można sprawdzić tylko w punkcie, w którym można je naprawić. Większość kodu aplikacji można napisać prostoliniowo, ponieważ funkcje zwrócą użyteczną wartość lub zgłoszą wyjątek.

Wyjątkiem powinno być poinformowanie użytkownika o wyjątkowych okolicznościach. Jeśli coś pójdzie nie tak z systemem, program powinien wiedzieć i mieć możliwość właściwej obsługi *.

To powiedziawszy, nie, nie istnieje wyjątek zapobiegający „awarii” systemu. Wyjątkiem jest informowanie mnie o problemie. Postępowanie określa, czy system może się zawiesić.

Pamiętaj również, że wyjątek nie musi kończyć aplikacji, jak już powiedziałeś. Programista może obsłużyć wyjątek i poprawić go lub zmienić w znaczący błąd dla użytkownika.

* Korzystanie ze sprawdzonych wyjątków (wyjątków, które są zmuszane do złapania) jest trochę obolałe. Niektórzy (być może większość) deweloperów uważa, że ​​wymuszona obsługa wyjątków jest uciążliwa, niepotrzebna i po prostu zła praktyka.

Wyjątki umożliwiają nowoczesną obsługę błędów, dzieląc lokalizację błędu z procedury obsługi błędów. Czasami służy to również do kontroli przepływu.

Nieobsługiwane wyjątki powodują zakończenie programu. Ale nie różnią się one od poprzednich wyjątków, po prostu leniwy programista, który zapomniał dołączyć odpowiednie procedury obsługi błędów do każdej ścieżki, czyni je widocznymi dla użytkownika końcowego. Uważam, że program zakończony przez wyjątek uległ awarii tak samo, jak każdy inny nieoczekiwany koniec.

Systemy operacyjne są bardzo dobre w czyszczeniu zawieszonych procesów bez względu na to, w jaki sposób ulegały awariom, więc wyjątki nie zwiększają bezpieczeństwa systemu operacyjnego w żaden inny sposób niż zakończenie nieprawidłowo działających procesów i uwolnienie zasobów.

To jest bardzo proste.

• Aby tylko zawiesić program, a nie cały system - mamy [dobre] systemy operacyjne.
• Aby zawiesić program zamiast ignorować błąd krytyczny - mamy wyjątki.

Przed wynalezieniem wyjątków każda funkcja musiała zwrócić kod wyjścia (błąd / sukces), a każdy wynik lub wynik funkcji musiał zostać pobrany przez przekazanie wskaźnika do pamięci, aby został przez nią ustawiony.

Problem polegał na tym, że wielu programistów nie pamiętało / nie zawracało sobie głowy sprawdzaniem błędnych kodów wyjścia dla każdej funkcji, a zatem błędy krytyczne były czasami ignorowane, co prowadzi do dość niewyjaśnionych zachowań.

Dlatego postanowiono - gdy wystąpi błąd, którego nie wziąłeś pod uwagę, natychmiast się zawiesi! Obsługa wyjątków AKA.

Wyjątki to po prostu mechanizm wykrywania błędów. Same w sobie nie są przydatne.

Ale wykrywając błąd, pozwalają uruchomić mechanizmy tolerancji na awarie, aby wyjść ze stanu błędnego, przechodząc do stanu wolnego od błędów (poprzedniego lub nowego). W ten sposób błąd nie jest propagowany do innych części systemu.

Istnieją wyjątki, aby oddzielić normalny przepływ programu (do czego program jest przeznaczony) od przepływu obsługi błędów (w jaki sposób program próbuje naprawić sytuację wyjątkową).

Dzięki temu kod jest bardziej przejrzysty i łatwiejszy w utrzymaniu.

Rozważ dwa fragmenty kodu:

try:
    do1()  # this is obvoiusly a normal
    do2()  # program flow
except:
    oups()  # this is exception handling code

W porównaniu do tego:

if foo():
    thing1()  # is this part of normal program flow?
else:
    thing2()  # or maybe this one? Or both? When?

Oczywiście można zastosować obsługę wyjątków, aby zapobiec awariom programu przez:

try {    // very bad code
    my();
    whole();
    ugly();
    application();
    here();
} catch (Throwable t) {
    // pretend it's ok
}

ale nie jest to powodem wyjątków we współczesnych językach programowania.

Możesz także użyć whilei breakzamiast tego, ifale nie do tego jest to whilei po co break.