w którym przestrzeń nazw/paczka do wstawiania wyjątków

Question

Jaka jest najczęstsza lub najlepsza praktyka do struktury położenia klas wyjątków?

Powiedzmy masz pakietów/przestrzenie nazw myproject.person (modele i DAOs dla osób) oraz myproject.order (modele i DAOs dla zleceń) oraz wyjątki PersonException i OrderException. Czy należy umieszczać wyjątki w ich odpowiednich pakietach lub w osobnym pakiecie z wyjątkami (na przykład myproject.exceptions)?

Pierwsze podejście wydaje się bardziej uzasadnione (ponieważ jest posortowane według funkcjonalności). Ale pojawia się pytanie, gdzie należy umieścić wyjątki, które są związane z oboma? na przykład ConstraintViolationException

Dzięki

Answer 1

Umieściłbym je w tej samej przestrzeni nazw co odpowiadające im klasy. W przypadku bardziej ogólnych typów wyjątków powinieneś spróbować umieścić je w najbardziej specyficznym obszarze nazw, który obejmuje klasy, które ich używają, więc wyjątek ConstraintViolationException byłby w przestrzeni nazw myproject.

Answer 2

Z mojego doświadczenia wynika, że ​​najlepiej jest umieścić wyjątki w pakietach, które mają sens dla tego wyjątku. Nie tworzyłbym specjalnego pakietu dla wyjątków - wyjątki powinny żyć w pobliżu klas, które z nich korzystają.

Answer 3

Zrób to, co robi biblioteka klas Java. Umieść wyjątki w tych samych pakietach co klasy API i interfejsy, które je rzucają.

Answer 4

Po prostu zachowuję wszystkie wyjątki w przestrzeni nazw projektu (np. Myproject). Mogą zająć miejsce w widoku projektu, jeśli utworzysz jeden plik na klasę, więc zazwyczaj wywoływany jest plik (wyjątki) .cs, aby pojawiały się na górze i umieszczać wszystkie execepty w jednym miejscu.

Jeśli jest to duży projekt, to zazwyczaj dzieli podzespoły na różne przestrzenie nazw, a każda przestrzeń nazw otrzyma własny zestaw wyjątków, ale mówimy o ponad 100 klasach na zespół.

Answer 5

Jeśli wyjątek używa tylko jednej klasy lub functuionality grupy klas umieścić go w pobliżu. Jeśli wyjątek ma wspólne znaczenie dla biblioteki jr aplikacji, umieść go w przestrzeni nazw oun. IMHO

Answer 6

Problem mam z tego całego pomysłu jest to, że wyjątki powinny być generalnie zaprojektowany na wzór tego, co może się nie udać, takie jak NullPointerException, natomiast PersonException wydaje się odnosić do obiektu zaangażowany w cokolwiek katastrofa rozwija się, nie dając wskazówka, co poszło nie tak. Czy obiekt Person spowodował wyjątek? Czy to dlatego, że osoba ma problem z wewnętrzną logiką, czy dlatego, że do jednej z jej metod dostarczono złe argumenty? Czy był wyjątek z powodu braku osoby w bazie danych?

To, że masz dwa zdanie na temat wyjątków dotyczących obu obiektów, tylko wzmacnia moje obawy. Sugeruję ponowne przemyślenie projektu wyjątków (EntityNotFoundException, BadArgumentException, MinorCannotOrderPornException), a odpowiedź na twój dylemat będzie miejmy nadzieję bardziej oczywista.

Answer 7

Wyobraźmy sobie, że każdy zespół ma swoje własne działania, a wiele rodzajów wyjątków (nie tylko PersonException lub OrderException, ale PersonInvalidDataException lub PersonDataPersistException). Te wyjątki mogą implementować wyjątek BaseException, który na przykład loguje się i wysyła wiadomości e-mail.

Tak więc bardziej przystępnym sposobem (moim zdaniem) jest rozdzielenie ich według przestrzeni nazw.