Masz rację.
Niezaznaczone wyjątki są używane, aby system mógł szybko zawieść, co jest dobrą rzeczą. Powinieneś jasno określić, czego oczekuje Twoja metoda, aby działać poprawnie. W ten sposób możesz zweryfikować dane wejściowe tylko raz.
Na przykład:
/**
* @params operation - The operation to execute.
* @throws IllegalArgumentException if the operation is "exit"
*/
public final void execute( String operation ) {
if( "exit".equals(operation)){
throw new IllegalArgumentException("I told you not to...");
}
this.operation = operation;
.....
}
private void secretCode(){
// we perform the operation.
// at this point the opreation was validated already.
// so we don't worry that operation is "exit"
.....
}
Żeby dać przykład. Chodzi o to, że jeśli system szybko zawiedzie, będziesz wiedział, gdzie i dlaczego zawiódł. Dostaniesz ślad stosu, taki jak:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
I będziesz wiedział, co się stało. Klasa OtherClass w metodzie „delegateTheWork” (w linii 4569) wywołała twoją klasę z wartością „exit”, nawet jeśli nie powinna itp.
W przeciwnym razie będziesz musiał posypać sprawdzanie poprawności całym kodem, co jest podatne na błędy. Ponadto czasami trudno jest wyśledzić, co poszło nie tak i możesz spodziewać się godzin frustrującego debugowania
To samo dzieje się z NullPointerExceptions. Jeśli masz klasę 700 linii z 15 metodami, która używa 30 atrybutów i żadna z nich nie może mieć wartości null, zamiast sprawdzania poprawności w każdej z tych metod pod kątem dopuszczalności zerowania, możesz ustawić wszystkie atrybuty tylko do odczytu i zweryfikować je w konstruktorze metoda fabryczna.
public static MyClass createInstane( Object data1, Object data2 /* etc */ ){
if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }
}
// the rest of the methods don't validate data1 anymore.
public void method1(){ // don't worry, nothing is null
....
}
public void method2(){ // don't worry, nothing is null
....
}
public void method3(){ // don't worry, nothing is null
....
}
Sprawdzone wyjątki Są przydatne, gdy programista (ty lub twoi współpracownicy) zrobił wszystko dobrze, sprawdził dane wejściowe, przeprowadził testy i cały kod jest doskonały, ale kod łączy się z usługą internetową innej firmy, która może być wyłączona (lub plik używany był usunięty przez inny proces zewnętrzny itp.). Usługa internetowa może nawet sprawdzić poprawność przed próbą nawiązania połączenia, ale podczas przesyłania danych coś poszło nie tak.
W tym scenariuszu nie ma nic, co Ty lub Twoi współpracownicy możecie zrobić, aby pomóc. Ale nadal musisz coś zrobić i nie pozwolić aplikacji po prostu umrzeć i zniknąć w oczach użytkownika. Używasz do tego sprawdzonego wyjątku i obsługujesz wyjątek. Co możesz zrobić, gdy tak się stanie ?, przez większość czasu, po prostu próbując zarejestrować błąd, prawdopodobnie zapisać swoją pracę (działanie aplikacji) i przekazać wiadomość użytkownikowi . (Strona blabla nie działa, spróbuj ponownie później itp.)
Jeśli zaznaczony wyjątek zostanie nadużywany (przez dodanie „wyjątku rzucania” we wszystkich sygnaturach metod), kod stanie się bardzo delikatny, ponieważ wszyscy zignorują ten wyjątek (ponieważ jest zbyt ogólny), a jakość kodu będzie poważnie poważna zagrożone.
Jeśli nadużyjesz niezaznaczonego wyjątku, wydarzy się coś podobnego. Użytkownicy tego kodu nie wiedzą, czy coś może pójść nie tak. Pojawi się dużo prób {...} catch (Throwable t).