Użytkownik wprowadzający " złe " wejście nie jest wyjątkiem: należy się tego spodziewać.

Wyjątki nie powinny być stosowane dla normalnego przepływu sterowania.

W przeszłości wielu autorów mówiło, że wyjątki są z natury drogie. Jon Skeet blogował wbrew temu (i wspomniał kilka razy w odpowiedziach tutaj NA SO), mówiąc, że nie są tak drogie ,jak zgłoszono (chociaż nie opowiadałbym się za używaniem ich w ciasnej pętli!)

Największym powodem ich użycia jest "oświadczenie woli" tj. jeśli widzisz blok obsługi wyjątków, natychmiast widzisz wyjątkowe przypadki, które są rozpatrywane poza normalnym przepływem.

Istnieje jeden ważny inny powód niż już wymienione:

Jeśli używasz WYJĄTKÓW tylko W wyjątkowych przypadkach, możesz uruchomić debuggera z ustawieniem "stop when exception is throwed". Jest to niezwykle wygodne, ponieważ wpadasz do debuggera na dokładnej linii, która powoduje problem. Korzystanie z tej funkcji oszczędza sporo czasu każdego dnia .

W C# jest to możliwe (i polecam z całego serca), zwłaszcza po dodaniu metod TryParse do wszystkich klas liczb. Ogólnie rzecz biorąc, żadna ze standardowych bibliotek nie wymaga ani nie używa "złej" obsługi wyjątków. Kiedy zbliżam się do kodu C#, który nie został napisany do tego standardu, zawsze kończę konwersję go do przypadków wolnych od wyjątków, ponieważ stop-om-throw jest tak cenny.

W firebug javascript debugger możesz również to zrobić, pod warunkiem, że Twoje biblioteki nie używają źle WYJĄTKÓW.

Kiedy programuję Java, nie jest to tak naprawdę możliwe, ponieważ tak wiele rzeczy używa WYJĄTKÓW w wyjątkowych przypadkach, w tym wiele standardowych bibliotek java. Ta funkcja oszczędzania czasu nie jest tak naprawdę dostępna do użytku w Javie. Uważam, że jest to spowodowane sprawdzonymi wyjątkami, ale nie zacznę narzekać na to, jak są złe.

Błędy i wyjątki – co, kiedy i gdzie?

Wyjątki mają na celu zgłaszanie błędów, co czyni kod bardziej solidnym. Aby zrozumieć, kiedy używać wyjątków, należy najpierw zrozumieć, czym są błędy, a co nie jest błędem.

Funkcja jest jednostką pracy, a awarie powinny być postrzegane jako błędy lub w inny sposób na podstawie ich wpływu na funkcje. W funkcji f błąd jest błędem wtedy i tylko wtedy, gdy uniemożliwia f spełnienie któregokolwiek z jej calee ' s preconditions , osiągnięcie dowolnego z F 's own postconditions , lub przywrócenie dowolnego niezmiennego , który f ponosi odpowiedzialność za utrzymanie.

Istnieją trzy rodzaje błędów:

• warunek, który uniemożliwia spełnianie warunku (np. ograniczenia parametrów) innej funkcji, która musi być wywołana;
• warunek, który uniemożliwia funkcji ustanowienie jednego z jej własnych warunków ( np. uzyskanie poprawnej wartości zwracanej jest stanem postkondensacyjnym); oraz
• warunek, który uniemożliwia funkcji przywrócenie niezmiennika, który jest odpowiedzialny za utrzymanie. Jest to szczególny rodzaj postkondencji, który odnosi się szczególnie do funkcji Członkowskich. Istotnym warunkiem postkondystencji każdej Nie-prywatnej funkcji członka jest to, że musi ona przywrócić niezmienniki swojej klasy.

Każdy inny warunek jest a nie błędem i nie powinien być zgłaszany jako błąd.

Dlaczego wyjątki są tak złe dla walidacji danych wejściowych?

Myślę, że jest to spowodowane nieco niejednoznacznym rozumieniem "input" jako znaczenia wejścia funkcji lub wartości pola, gdzie to ostatnie nie powinno rzucać wyjątku, chyba że jest częścią funkcji, która nie działa.

1. Maintainability - wyjątki tworzą dziwne ścieżki kodu, w przeciwieństwie do GOTOs.
2. łatwość użycia (dla innych klas) - Inne klasy mogą zaufać, że wyjątki zgłoszone przez użytkownika Klasa input to rzeczywiste błędy
3. Performance - w większości języków, an wyjątek wiąże się z występem i kara za użycie pamięci.
4. semantyka - znaczenie słów ma znaczenie. Złe wejście nie jest "wyjątkowy".

Myślę, że różnica zależy od kontraktu danej klasy, czyli

Dla kodu, który ma radzić sobie z danymi wejściowymi użytkownika i programować je w sposób Defensywny (tzn. dezynfekować) błędem byłoby rzucanie wyjątku dla nieprawidłowych danych wejściowych - jest to oczekiwane.

Dla kodu, który ma radzić sobie z już wyczyszczonymi i zwalidowanymi danymi wejściowymi, które mogły pochodzić od użytkownika, rzucenie wyjątku byłoby poprawne, jeśli znajdziesz jakieś dane wejściowe, które mają być zakazane. Na kod wywołujący narusza w tym przypadku umowę i wskazuje na błąd w kodzie wywołującym i/lub dezaktywującym.

Podczas używania WYJĄTKÓW, kod obsługi błędów jest oddzielony od kodu powodującego błąd . Taka jest intencja obsługi wyjątków - jako wyjątkowy warunek, błąd nie może być obsługiwany lokalnie, więc wyjątek jest wyrzucany do jakiegoś Wyższego (i nieznanego) zakresu. Jeśli aplikacja nie zostanie obsłużona, zakończy działanie, zanim zrobi się jeszcze trudniej.

Jeśli kiedykolwiek, kiedykolwiek, kiedykolwiek rzucasz wyjątek podczas wykonywania prostych operacji logicznych, takich jak weryfikacja danych użytkownika, robisz coś bardzo, bardzo, bardzo złego.

Wejście nie jest tym, czego oczekiwano i stąd jest wyjątkowy.

To stwierdzenie wcale mi nie odpowiada. Interfejs użytkownika ogranicza wprowadzanie danych przez użytkownika (np. użycie suwaka ograniczającego wartości min/max) i można teraz określić pewne warunki - nie jest wymagana obsługa błędów. Albo użytkownik może wprowadzić śmieci i oczekujesz, że tak się stanie i musisz sobie z tym poradzić. Jedno czy drugie - nie ma tu wyjątku cokolwiek.

Rzucenie wyjątku pozwala mi zdefiniuj dokładnie, co było złe StringValueTooLong lub IntegerValueTooLow lub InvalidDateValue albo cokolwiek. Dlaczego jest to brane pod uwagę źle?

Uważam to za ponad-bliżej zła. Możesz zdefiniować abstrakcyjny interfejs ErrorProvider lub zwrócić złożony obiekt reprezentujący błąd, a nie prosty kod. Istnieje wiele, wiele opcji pobierania raportów o błędach. Używanie wyjątków, ponieważ są wygodne jest więc, tak źle . Czuję się brudny pisząc ten akapit.

Pomyśl o rzuceniu wyjątku jako o nadziei. Ostatnia szansa. Modlitwa. Walidacja danych wejściowych użytkownika nie powinna prowadzić do żadnego z tych warunków.

Czy to możliwe, że część nieporozumień wynika z braku konsensusu co do tego, co oznacza "wkład użytkownika"? I rzeczywiście, na jakiej warstwie kodujesz.

Jeśli kodujesz interfejs użytkownika GUI lub funkcję obsługi formularzy internetowych, możesz spodziewać się nieprawidłowego wejścia, ponieważ pochodzi ono bezpośrednio z palców człowieka.

Jeśli kodujesz część modelową aplikacji MVC, być może zaprojektowałeś coś tak, aby kontroler miał dla Ciebie dane wejściowe. Nieprawidłowe dane wejściowe otrzymywane jako o ile model rzeczywiście byłby wyjątkiem i może być traktowany jako taki.

Jeśli kodujesz serwer na poziomie protokołu, możesz oczekiwać, że klient będzie sprawdzał dane wejściowe użytkownika. Ponownie, niepoprawne wejście tutaj rzeczywiście byłoby wyjątkiem. Jest to zupełnie inna sytuacja niż zaufanie klientowi w 100% (to byłoby naprawdę bardzo głupie) - ale w przeciwieństwie do bezpośredniego wejścia użytkownika, przewidujesz, że większość wejść czasowych będzie OK. Linie nieco się zacierają. Tym bardziej prawdopodobne jest, że coś się dzieje, tym mniej chcesz używać WYJĄTKÓW do obsługi tego.

jest to lingwistyczny pov (punkt widzenia) w tej sprawie.

Dlaczego wyjątki są tak złe dla walidacji danych wejściowych?

Wniosek:

• wyjątki nie są wystarczająco jasno określone, więc istnieją różne opinie.
• złe wejście jest postrzegane jako normalna rzecz, a nie jako wyjątek.

Myśli ?

To prawdopodobnie sprowadza się do oczekiwań, jakie trzeba wziąć co do kodu, który jest tworzony.

• klient nie może być zaufany
  • Walidacja mA nastąpić po stronie serwera. silniejszy : każda Walidacja odbywa się po stronie serwera.
  • ponieważ Walidacja odbywa się po stronie serwera, oczekuje się, że zostanie tam wykonana, a to, czego się oczekuje, nie jest wyjątkiem, ponieważ jest oczekiwane.

Jednak

• Dane wejściowe klienta nie można ufać
• Wejście klienta - Walidacja can be zaufany
  • jeśli Walidacja jest zaufana, można oczekiwać, że wytworzy poprawne dane wejściowe
  • teraz oczekuje się, że każde wejście będzie poprawne
  • invalid input is now unexpected, an exception

.

Wyjątki mogą być dobrym sposobem na wyjście z kodu.

Należy rozważyć, czy Twój kod jest pozostawiony w odpowiednim stanie. Nie wiedziałbym, co zostawiłoby mój kod w niewłaściwym stanie. Połączenia są zamykane automatycznie, zmienne są zbierane śmieci, w czym problem?

Kolejny głos przeciwko obsłudze wyjątków dla rzeczy, które nie są wyjątkami!

1. W. NET kompilator JIT nie wykonuje optymalizacji w pewnych przypadkach, nawet jeśli wyjątki nie są wyrzucane. Poniższe artykuły wyjaśniają to cóż. http://msmvps.com/blogs/peterritchie/archive/2007/06/22/performance-implications-of-try-catch-finally.aspx http://msmvps.com/blogs/peterritchie/archive/2007/07/12/performance-implications-of-try-catch-finally-part-two.aspx

2. Kiedy wyjątek zostanie wyrzucony, generuje całą masę informacji dla śladu stosu, które mogą nie być potrzebne, jeśli faktycznie "spodziewałeś się" wyjątku, jak to często ma miejsce podczas konwersji łańcuchów do int itd...

Ogólnie rzecz biorąc, biblioteki wyrzucają wyjątki, a klienci je łapią i robią z nimi coś inteligentnego. Dla wejścia użytkownika po prostu piszę funkcje walidacji zamiast rzucać wyjątki. Wyjątki wydają się przesadne dla czegoś takiego.

Istnieją problemy z wydajnością z wyjątkami, ale w kodzie GUI generalnie nie musisz się o nie martwić. Co z tego, że Walidacja wymaga dodatkowych 100 ms do uruchomienia? Użytkownik tego nie zauważy.

W pewnym sensie to trudna decyzja - Z jednej strony możesz nie chcieć, aby cała aplikacja upadła, ponieważ użytkownik wprowadził dodatkową cyfrę w polu tekstowym kodu pocztowego i zapomniałeś obsłużyć wyjątek. Z drugiej strony, podejście "Fail early, Fail hard" zapewnia szybkie wykrywanie i naprawianie błędów oraz utrzymanie cennej bazy danych przy zdrowych zmysłach. Ogólnie myślę, że większość frameworków zaleca, aby nie używać obsługi wyjątków do sprawdzania błędów interfejsu użytkownika, a niektóre, takie jak. NET Windows Forms, zapewniają ładne sposoby to (Errorprovidery i zdarzenia walidacji) bez wyjątków.

Wyjątki nie powinny być używane do walidacji danych wejściowych, ponieważ nie tylko wyjątki powinny być używane w wyjątkowych okolicznościach (które, jak zostało zaznaczone, nie są błędnymi wpisami użytkownika), ale tworzą wyjątkowy kod (Nie w genialnym sensie).

Problem z wyjątkami w większości języków polega na tym, że zmieniają one reguły przepływu programu, jest to w porządku w naprawdę wyjątkowych okolicznościach, gdzie niekoniecznie jest możliwe określenie naszego, jaki powinien być prawidłowy przepływ i dlatego po prostu wyrzuć wyjątek i wyjdź jednak tam, gdzie wiesz, jaki powinien być przepływ, powinieneś utworzyć ten przepływ (w wymienionym przypadku byłoby podniesienie Wiadomości do użytkownika, informując go, że musi ponownie wprowadzić pewne informacje).

Wyjątki były naprawdę nadużywane w aplikacji, nad którą pracuję codziennie, a nawet w przypadku, gdy użytkownik wprowadził nieprawidłowe hasło podczas logowania, co według Twojej logiki byłoby wynikiem wyjątku, ponieważ nie jest to, czego chce aplikacja. Jednakże kiedy proces ma jeden z dwóch wyników albo poprawne lub nieprawidłowe, Nie sądzę, że możemy powiedzieć, że, nieprawidłowe, bez względu na to, jak źle, jest wyjątkowy.

Jednym z głównych problemów, jakie znalazłem podczas pracy z tym kodem, jest próba podążania za logiką kodu bez angażowania się głęboko w debugger. Chociaż Debugery są świetne, powinno być możliwe dodanie logiki do tego, co dzieje się, gdy użytkownik wprowadzi nieprawidłowe hasło bez konieczności uruchamiania jednego z nich.

Zachowaj wyjątki za naprawdę wyjątkowe wykonanie nie tylko złe. W przypadku, gdy podkreślałem, że błędne hasło nie jest wyjątkowe, ale brak możliwości skontaktowania się z serwerem domeny może być!

Kiedy widzę wyjątki wyrzucane za błędy walidacji, często widzę, że metoda rzucająca wyjątek wykonuje wiele walidacji na raz. np.

public bool isValidDate(string date)
{
    bool retVal = true;
    //check for 4 digit year
    throw new FourDigitYearRequiredException();
    retVal = false;

    //check for leap years
    throw new NoFeb29InANonLeapYearException();
    retVal = false;
    return retVal;
}

Ten kodeks wydaje się być dość kruchy i trudny do utrzymania, ponieważ zasady piętrzą się przez miesiące i lata. Zazwyczaj wolę podzielić moje walidacje na mniejsze metody, które zwracają Boole. Ułatwia to dostosowanie zasad.

public bool isValidDate(string date)
{
    bool retVal = false;
    retVal = doesDateContainAFourDigitYear(date);
    retVal = isDateInALeapYear(date);
    return retVal;
}

public bool isDateInALeapYear(string date){}

public bool doesDateContainAFourDigitYear(string date){}

Jak już wspomniano, zwracanie błędu struct / object podanie informacji o błędzie to świetny pomysł. Najbardziej oczywistą zaletą jest to, że można je zebrać i wyświetlić wszystkie komunikaty o błędach do użytkownika na raz, zamiast ich grać Whack-A-Mole z walidacji.

Użyłem kombinacji obu rozwiązań: dla każdej funkcji walidacji przekazuję rekord, który wypełniam statusem walidacji (kodem błędu). na końcu funkcji, jeśli istnieje błąd walidacji, rzucam wyjątek, w ten sposób nie rzucam wyjątku dla każdego pola, ale tylko raz. skorzystałem również z tego, że wyrzucenie wyjątku zatrzyma wykonanie, ponieważ nie chcę, aby wykonanie było kontynuowane, gdy dane są nieprawidłowe.

Na przykład

procedure Validate(var R:TValidationRecord);
begin
  if Field1 is not valid then
  begin
    R.Field1ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end; 
  if Field2 is not valid then
  begin
    R.Field2ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;
  if Field3 is not valid then
  begin
    R.Field3ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;

  if ErrorFlag then
    ThrowException
end;

Jeśli opierając się na tylko boolean, programista korzystający z mojej funkcji powinien wziąć to pod uwagę pisząc:

if not Validate() then
  DoNotContinue();

Ale może zapomniał i tylko wywołał Validate () (wiem, że nie powinien, ale może może).

Więc w powyższym kodzie zyskałem dwie zalety: 1-tylko jeden wyjątek w funkcji walidacji. 2-wyjątek, nawet nieobciążony, zatrzyma wykonanie i pojawi się w czasie testu.

8 lat później, i mam ten sam dylemat próbując zastosować wzór CQS. Jestem po stronie, że walidacja danych wejściowych może rzucić wyjątek, ale z dodanym ograniczeniem. Jeśli jakiekolwiek wejście nie powiedzie się, musisz rzucić jeden typ wyjątku: ValidationException, BrokenRuleException, itd. Nie rzucać kilka różnych typów, jak to będzie niemożliwe, aby obsłużyć je wszystkie. W ten sposób otrzymasz listę wszystkich złamanych zasad w jednym miejscu. Tworzysz jedną klasę, która jest odpowiedzialna za validation (SRP) i rzuca wyjątek, jeśli co najmniej 1 reguła jest złamana. W ten sposób radzisz sobie z jedną sytuacją z jednym haczykiem i wiesz, że jesteś dobry. Możesz poradzić sobie z tym scenariuszem bez względu na to, jaki kod jest nazywany. To pozostawia cały kod na dole o wiele czystszy, ponieważ wiesz, że jest w prawidłowym stanie, inaczej nie dostałby się tam.

Dla mnie uzyskanie nieprawidłowych danych od użytkownika nie jest czymś, czego normalnie byś się spodziewał. (Jeśli każdy użytkownik wyśle Ci niepoprawne dane za pierwszym razem, wziąłbym drugie spojrzenie na twój interfejs.) Wszelkie dane, które uniemożliwiają przetwarzanie prawdziwych intencji, niezależnie od tego, czy są to dane użytkownika, czy pochodzą z innego miejsca, muszą przerwać przetwarzanie. Czym to się różni od rzucania Argumentunullexception z pojedynczego kawałka danych, jeśli było to wejście użytkownika VS. jest to pole na klasie, która mówi, że jest to wymagane.

Jasne, możesz najpierw zrobić walidację i napisać ten sam kod na każdym "poleceniu" , ale myślę, że jest to koszmar konserwacyjny niż łapanie nieprawidłowe dane wejściowe użytkownika w jednym miejscu na górze, które niezależnie od tego są obsługiwane w ten sam sposób. (Mniej kodu!) Trafienie wydajności nastąpi tylko wtedy, gdy użytkownik poda nieprawidłowe dane, co nie powinno się zdarzać tak często (lub masz zły UI). Wszelkie zasady po stronie klienta muszą być ponownie napisane na serwerze, tak więc możesz je po prostu napisać raz, wykonać połączenie AJAX, a opóźnienie

Także, gdy ty może zrobić porządną walidację z ASP.NET po wyjęciu z pudełka, jeśli chcesz ponownie użyć logiki walidacji w innych interfejsach użytkownika, nie możesz, ponieważ jest wypiekany do ASP.NET. lepiej byłoby stworzyć coś poniżej i obsługiwać to powyżej, niezależnie od używanego interfejsu użytkownika. (Przynajmniej moje 2 centy.)

Zgadzam się z Mitchem, że "wyjątki nie powinny być używane dla normalnego przepływu sterowania". Chcę tylko dodać, że z tego, co pamiętam z moich zajęć z informatyki, łapanie wyjątków jest drogie. Nigdy tak naprawdę nie próbowałem robić benchmarków, ale byłoby interesujące porównanie wydajności między powiedzmy, if / else vs try / catch.

Jeden problem z używaniem WYJĄTKÓW to tendencja do wykrywania tylko jednego problemu na raz. Użytkownik naprawia to i resubmits, tylko znaleźć inny problem! Interfejs, który zwraca listę spraw, które wymagają rozwiązania, jest o wiele bardziej przyjazny (choć może być zawinięty w wyjątek).