Łapanie kilku wyjątków i ponowne generowanie ogólnego wyjątku

Question

Używam refleksji, aby dodać trochę danych do prywatnej zmiennej wewnątrz klasy z biblioteki innej firmy. Po drodze istnieje około czterech różnych Wyjątków, które można rzucać; wszystkie są związane z refleksją, a wszystkie z nich są mało prawdopodobne. Ciężko koduję nazwę zaangażowanej klasy i zmiennej. Jest mało prawdopodobne, że otrzymam błędy nie znalezionej klasy lub pola nie znaleziono, chyba że biblioteka zostanie uaktualniona i zmieniła się znacząco.

Wolałbym nie zgłaszać wszystkich czterech wyjątków dla mojego rozmówcy. Prawdopodobnie nigdy ich nie zobaczy. Chciałbym po prostu złapać wszystkie te i rzucić inny wyjątek, aby powiedzieć "Wystąpił błąd odbicia Java, jest prawdopodobne, że biblioteka została uaktualniona i zmieniona w sposób niezgodny z tą metodą." Czy istnieje standardowy wyjątek Java, który można wyrzucić, co oznacza tylko ogólny błąd odbicia? Czy powinienem zdefiniować własne? A może najlepiej byłoby po prostu zadeklarować, że ta metoda może rzucić wszystkie możliwe wyjątki od refleksji?

Answer 1

Możesz zamienić wszystkie wyjątki w AssertionError, jeśli nie spodziewasz się, że wystąpią. InvocationTargetException można rozpakować, jeśli chcesz zająć się określonym wyjątkiem. Jeśli chcesz rzucić rzeczywisty wyjątek rzucony metodą zamiast InvocationTargetException można wykorzystać ten trick, ale może być bardziej kłopotliwe niż użyteczny

} catch (InvocationTargetException e) { 
    // Throw any exception in the current thread (even if it is a checked exception) 
    Thread.currentThread().stop(e.getCause()); 
} 

Answer 2

Zazwyczaj zadaję sobie te pytania:

• Can kogo nazywa ten sposób obsłużyć te różne rodzaje wyjątków inaczej?
• ... A może potraktują je tak samo?
• Czy osoba dzwoniąca/użytkownik może nawet odzyskać ten błąd?

Jeśli kod wywołujący może traktować wszystkie te cztery wyjątki jako takie (jako nieodwracalny błąd), wówczas absolutnie sensowne jest uchwycenie każdego z nich i ponowne zgłoszenie bardziej ogólnego (pojedynczego) wyjątku. Jeśli tak, upewnij się, że dołączony wygenerowany wyjątek jest wewnętrznym wyjątkiem, aby pomóc w debugowaniu lub rozwiązywaniu problemów na drugim końcu.

Answer 3

Istnieje kilka kontrowersji dotyczących sprawdzonych i niezaznaczonych wyjątków. Osobiście uważam, że wyjątki kontrolowane są najgorszym pomysłem w Javie - ale to tylko opinia (ale nie jestem sama myśląc o tym)

W każdym razie myślę, że ważną rzeczą byłoby zmienić je na pojedynczy niezaznaczony wyjątek . Najczęściej używam pojedynczego, takiego jak IllegalStateException lub IllegalParameterException - z jasnym opisem tekstu, te dwa wyjątki obejmują 90% bzdur, które mogą pójść nie tak z metodą.

Answer 4

Nie sądzę, że ma sens deklarowanie wyjątków w tym przypadku. Więc chciałbym złapać wyjątki od refleksji, może zalogować ślad stosu i rzucić jakiś wyjątek RuntimeException, który ma tę zaletę, że nie trzeba go deklarować. Możesz po prostu użyć RuntimeException z odpowiednim komunikatem, jeśli jesteś leniwy.

Answer 5

Po pierwsze, nie używaj odbicia, chyba że naprawdę, naprawdę musisz, ponieważ jest złe. Zakładając, że musisz:

Ponieważ nadpisujesz wszystkie nazwy, po prostu pozostawia Method.invoke, Constructor.newInstance i Field.get/set. Sugerowałbym ponowne wyrzucenie sprawdzonych wyjątków, które można opatrzyć zapakowanymi w Error. Nie powinny się zdarzyć, a jeśli chcesz sobie z tym poradzić, proponuję sprawdzenie czasu intializacji klasy. InvocationTargetException powinno się oczywiście rozpakować i poradzić sobie w odpowiedni sposób (wyrzucić zapakowany Error dla sprawdzanego wyjątku, którego metoda/konstruktor nie zadeklarował).

Answer 6

Jak posiadające tych klas wyjątków rozszerzonych z GeneralException i połowu że ten wyjątek GeneralException?

Spróbuję tego teraz! :)