Na przykład wiele metod w frameworkach / JDK może generować
java.lang.SecurityException
ale nie jest to wskazane w sygnaturze metody (ponieważ jest to praktyka zwykle zarezerwowana dla sprawdzonych wyjątków). Chcę argumentować, że deklarowanie wyjątków RuntimeExceptions w sigs metod ma wiele zalet (na przykład podobne do statycznego sprawdzania typu). Jestem pijany czy nie?
Odpowiedzi:
Nie deklarowałbym niezaznaczonego wyjątku w podpisie, ponieważ wprowadza on w błąd użytkownika tego interfejsu API. Nie jest już oczywiste, czy wyjątek musi być jawnie obsługiwany.
Zadeklarowanie go w javadoc jest lepszym podejściem, ponieważ pozwala komuś zająć się tym, jeśli uważa, że jest to konieczne, ale wiedząc, że może to zignorować, jeśli chce. To sprawia, że rozdział między zaznaczonymi i niezaznaczonymi jest wyraźny.
„Jeśli tak dobrze jest udokumentować API metody, w tym wyjątki, które może generować, dlaczego nie określić również wyjątków czasu wykonywania?” Wyjątki środowiska wykonawczego reprezentują problemy, które są wynikiem problemu programistycznego i jako takie nie można rozsądnie oczekiwać, że kod klienta API po nich odzyska lub poradzi sobie z nimi w jakikolwiek sposób. Takie problemy obejmują wyjątki arytmetyczne, takie jak dzielenie przez zero; wyjątki dotyczące wskaźnika, takie jak próba uzyskania dostępu do obiektu przez odwołanie o wartości null; i wyjątki indeksowania, takie jak próba uzyskania dostępu do elementu tablicy za pośrednictwem indeksu, który jest za duży lub za mały.
Wyjątki w czasie wykonywania mogą wystąpić w dowolnym miejscu programu, aw typowym programie mogą być bardzo liczne. Konieczność dodania wyjątków czasu wykonywania w każdej deklaracji metody zmniejszyłaby przejrzystość programu.
Spójrz na javadoc dla Collection # add
Wspomniano o całej masie niezaznaczonych wyjątków:
Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.
Jeśli masz cierpliwość, polecam dokładnie udokumentować w ten sposób możliwe wyjątki generowane przez twoje metody. W pewnym sensie jest to jeszcze ważniejsze, aby zrobić to dla niezaznaczonych wyjątków, ponieważ sprawdzone wyjątki są w pewnym stopniu samodokumentujące (kompilator wymusza na kodzie wywołującym ich potwierdzenie).
throwsw sygnaturze metody. To nie to samo. Tak, absolutnie powinieneś udokumentować wszystkie wyjątki generowane przez Twój interfejs API, ale nie o to chodzi.
Z mojego punktu widzenia lepiej jest zadeklarować wyjątki czasu wykonywania przynajmniej w javadoc dla metody. Zadeklarowanie tego w podpisie czyni jeszcze bardziej oczywistym, co może się stać, gdy coś pójdzie nie tak. To jest mój główny powód, dla którego sugeruję podanie tych informacji.
Do Twojej wiadomości: w miarę upływu czasu (obecnie w 2017 r.) Skłaniam się teraz znacznie bardziej do dokumentowania ich wyłącznie w javadoc i unikania sprawdzonych wyjątków w miarę możliwości.
Moim zdaniem niesprawdzone wyjątki nigdy nie powinny być deklarowane w sygnaturze metody, ponieważ jest to sprzeczne z ich naturą.
Jeśli jednak metoda prawdopodobnie wyrzuci kilka niezaznaczonych wyjątków, zauważenie prawdopodobnych okoliczności w @throws w Javadoc może być pomocne dla innych wywołujących metodę w zrozumieniu, co może pójść nie tak. Jest to przydatne tylko w przypadku wyjątków, które wywołujący prawdopodobnie będą w stanie obsłużyć (takich jak NPE z powodu złych danych wejściowych itp.)
Ma to związek z dyskusją dotyczącą zaznaczonych wyjątków . Większość zgodziłaby się, że wyjątki nie powinny być deklarowane w sygnaturach metod.
Omówiono również sposób korzystania z wyjątków środowiska uruchomieniowego . Zgadzam się z jednym plakatem, że wyjątki środowiska wykonawczego powinny oznaczać błąd programowania lub stan krytyczny. Więc nie ma wiele zasług w deklarowaniu ich w podpisie. Każda metoda może potencjalnie przez jedną.