Czy metody, które generują wyjątek RuntimeException, powinny wskazywać to w sygnaturze metody?

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?

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.

Z samouczka Oracle Java :

„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).

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.)

Jeśli piszesz interfejs API do użytku przez innych, istnieje wystarczający powód, aby wyraźnie udokumentować swój zamiar w interfejsie API i nie ma żadnych wad deklarowania wyjątków RuntimeExceptions w sygnaturze metody.

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ą.