Najlepsze praktyki postępowania z zaleceniami lub zalecenia? [Zamknięte]

Myślę, że dwa główne problemy z moimi programami to struktura / organizacja kodu i obsługa błędów. Czytam Code Complete 2, ale potrzebuję czegoś do przeczytania, aby móc pracować z potencjalnymi problemami.

Na przykład, jeśli na stronie internetowej coś się może zdarzyć tylko wtedy, gdy użytkownik manipuluje danymi za pomocą javascript, piszesz w tym celu? Ponadto, kiedy nie łapiesz błędów? Kiedy piszesz klasę, która oczekuje na wejście łańcucha i liczby int, a nie są one łańcuchem i liczbą int, czy to sprawdzasz, czy też pozwalasz, aby bąbelkowała do metody wywołującej, która przekazała niepoprawne parametry?

Wiem, że jest to szeroki temat, na który nie można odpowiedzieć w jednej odpowiedzi tutaj, więc szukam książki lub zasobu, który jest powszechnie akceptowany jako nauczanie prawidłowej praktyki obsługi wyjątków.

Jedną z dobrych rzeczy do zapamiętania jest obsługa wyjątków when there is a need.

W przypadku platformy programistycznej .NET postępuj zgodnie ze wskazówkami MSDN - Najlepsze praktyki dotyczące obsługi wyjątków , a także zapoznaj się z tym ładnym artykułem dotyczącym projektu kodu - Wyjątkowa obsługa najlepszych praktyk w .NET

Jednak następujące wytyczne są w większości prawdziwe dla każdej platformy programistycznej:

• Nie zarządzaj logiką biznesową z wyjątkami. Zamiast tego użyj instrukcji warunkowych. Jeśli kontrola może być wykonana za pomocą instrukcji if-else wyraźnie, nie używaj wyjątków, ponieważ zmniejsza to czytelność i wydajność (np. Kontrola zerowa, dzielenie przez kontrolę zerową). .

• Nazwy wyjątków muszą być jasne i znaczące, z podaniem przyczyn wyjątków.

• Zgłaszaj wyjątki dla warunków błędu podczas wdrażania metody. Np. Jeśli zwrócisz wartości -1, -2, -3 itd. Zamiast FileNotFoundException, ta metoda nie będzie zrozumiała.

• Złap specyficzne wyjątki zamiast najwyższej klasy wyjątków. Zapewni to dodatkową wydajność, czytelność i bardziej szczegółową obsługę wyjątków.

• Kontrola zerowa z warunkami warunkowymi nie jest alternatywą dla przechwytywania wyjątku NullPointerException. Jeśli metoda może zwrócić null, kontroluj ją za pomocą instrukcji if-else. Jeśli zwrot może zgłosić wyjątek NullPointerException, złap go.

• Staraj się nie odrzucać wyjątku ze względu na cenę. Bu, jeśli ponowne rzucenie było koniecznością, ponownie rzuć ten sam wyjątek zamiast tworzyć nowy wyjątek. Przyniesie to dodatkową wydajność. Możesz dodać dodatkowe informacje na każdej warstwie do tego wyjątku.

• Zdefiniuj własną hierarchię wyjątków, rozszerzając bieżącą klasę wyjątków (np. UserException, SystemException i ich podtypy) i używaj ich. W ten sposób możesz wyspecjalizować swoje wyjątki i zdefiniować moduł / warstwę wyjątków wielokrotnego użytku. więcej w tym linku