Czy nie jest dobrą praktyką zajmowanie się wyjątkami środowiska wykonawczego w kodzie?

Pracuję nad aplikacją Java i widzę, że wyjątki czasu wykonywania są obsługiwane w wielu miejscach. Na przykład,

try {
    // do something
} catch(NullPointerException e) {
    return null;
}

Moje pytania brzmią: kiedy dobrą praktyką jest zajmowanie się wyjątkami Runtime? Kiedy wyjątki powinny pozostać nieobsługiwane?

To zależy.

Na przykład Integer#parseIntwyrzuca NumberFormatException(który jest RTE), jeśli podany ciąg nie może zostać przeanalizowany. Ale na pewno nie chcesz, aby aplikacja uległa awarii tylko dlatego, że użytkownik napisał „x” w polu tekstowym, które było liczbą całkowitą? A skąd wiesz, czy ciąg może zostać przeanalizowany, chyba że spróbujesz go najpierw przeanalizować? Tak więc w tym przypadku RTE jest tylko sygnałem błędu, który powinien spowodować jakiś komunikat błędu. Można argumentować, że powinien to być sprawdzony wyjątek, ale co możesz zrobić - tak nie jest.

Wyjątki NullPointerExceptions są zwykle oznaką braku kontroli null. Zamiast więc łapać go w ten sposób, należy dodać odpowiedni test zerowy, aby upewnić się, że nie zostanie zgłoszony wyjątek.

Ale czasem właściwe jest obsługiwanie wyjątków RunTimeExcept. Na przykład, gdy nie można zmodyfikować kodu, aby dodać kontrolę zerową w odpowiednim miejscu, lub gdy wyjątkiem jest coś innego niż wyjątek NullPointerException.

Twój przykład postępowania z wyjątkami jest okropny. W ten sposób tracisz ślad stosu i dokładne informacje o problemie. I tak naprawdę nie rozwiązujesz tego, ponieważ prawdopodobnie wywołasz inny wyjątek NullPointerException w innym miejscu i uzyskasz mylące informacje o tym, co się wydarzyło i jak to rozwiązać.

Obsługuję Oczekiwane wyjątki tam, gdzie ich oczekuję. (Jak błędy odczytu / zapisu DB). Nieoczekiwane wyjątki. Gdzie indziej może oczekiwać wyjątku i mieć na to logikę.

Wyjątki powinny być właśnie… wyjątkami. Najlepszą praktyką przy stosowaniu wyjątków jest wykorzystanie ich do uwzględnienia sytuacji, w której dzieje się coś sprzecznego z tym, czego się spodziewałbyś. Klasycznym przykładem jest FileNotFoundException, który jest generowany, gdy pliku po prostu nie ma. Jeśli testujesz istnienie pliku, użyj File.exists (), ponieważ po prostu naciskasz 10-metrowym drążkiem, aby sprawdzić, czy coś nie trafi.

Można technicznie osiągnąć te same wyniki, otaczając go w próbach catch i używając pliku tak, jakby istniał, ale A) wyjątki są generalnie kosztowne pod względem zasobów i B) programiści zakładają, że masz na myśli istnienie pliku, gdyby był w try catch, co zwiększa ogólne zamieszanie w programie.

Jest wiele sytuacji, w których napiszę metodę, która pobiera pewną wartość z bazy danych. Tysiąc rzeczy może się nie udać, a ponieważ potrzebuję tylko jednej małej informacji, niewygodne jest otaczanie połączenia listą próbną zawierającą 5 różnych wyjątków. Więc złapię wyjątki w metodzie pobierania. Jeśli coś pójdzie nie tak, podejmę wszelkie odpowiednie działania, aby zamknąć połączenie z bazą danych lub cokolwiek innego w klauzuli ostatecznie i zwrócę null. Jest to dobra praktyka nie tylko dlatego, że upraszcza twój kod, ale również dlatego, że „null” wysyła tę samą wiadomość, którą mógłbyś otrzymać z wyjątku .. że coś nie poszło zgodnie z planem. Zarządzaj specyfikacjami wyjątków w metodzie pobierania, ale zarządzaj, co robić, gdy rzeczy nie są

Na przykład:

Integer getUserCount() {
   Integer result = null;
   try {
      // Attempt to open database and retrieve data
   } catch (TimeoutException e) {
      logger.error("Got a watch?");
   } catch (MissingDatabaseException e) {
      logger.error("What are you smoking?");
   } catch (PermissionsToReadException e) {
      logger.error("Did you *really* think you were getting away with that?");
   } catch (PressedSendButtonToHardException e) {
      logger.error("Seriously.. just back away from the computer... slowly..");
   } catch (WTFException e) {
      logger.error("You're on your own with this one.. I don't even know what happened..");
   } finally {
      // Close connections and whatnot
   }
   return result;
}

void doStuff() {
   Integer result = getUserCount();
   if(result != null) {
       // Went as planned..
   }
}

tak, poprawna obsługa wyjątków czasu wykonywania nie jest dobrą praktyką. Powodem jest to, że uważa się, że jest to kosztowne / wymaga dużej ilości pamięci.