Bạn hoàn toàn đúng.
Các ngoại lệ không được kiểm tra được sử dụng để cho hệ thống bị lỗi nhanh , đó là một điều tốt. Bạn nên nói rõ phương pháp của bạn mong đợi để hoạt động đúng. Bằng cách này, bạn có thể xác nhận đầu vào chỉ một lần.
Ví dụ:
/**
* @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"
.....
}
Chỉ để đưa ra một ví dụ. Vấn đề là, nếu hệ thống bị lỗi nhanh, thì bạn sẽ biết nó bị lỗi ở đâu và tại sao. Bạn sẽ nhận được một stacktrace như:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
Và bạn sẽ biết chuyện gì đã xảy ra. OtherClass trong phương thức "ủy nhiệm TheWork" (ở dòng 4569) đã gọi lớp của bạn với giá trị "thoát", ngay cả khi không nên, v.v.
Nếu không, bạn sẽ phải rắc các xác nhận lên toàn bộ mã của mình và đó là lỗi dễ xảy ra. Ngoài ra, đôi khi rất khó để theo dõi những gì đã sai và bạn có thể mong đợi hàng giờ gỡ lỗi bực bội
Điều tương tự cũng xảy ra với NullPulumExceptions. Nếu bạn có một lớp 700 dòng với khoảng 15 phương thức, sử dụng 30 thuộc tính và không có thuộc tính nào trong số chúng có thể là null, thay vì xác thực trong mỗi phương thức đó để vô hiệu hóa, bạn có thể làm cho tất cả các thuộc tính đó chỉ đọc và xác thực chúng trong hàm tạo hoặc phương pháp nhà máy.
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
....
}
Các ngoại lệ được kiểm tra Rất hữu ích khi lập trình viên (bạn hoặc đồng nghiệp của bạn) làm mọi thứ đúng, xác thực đầu vào, chạy thử nghiệm và tất cả mã đều hoàn hảo, nhưng mã kết nối với dịch vụ web của bên thứ ba có thể bị hỏng (hoặc tệp bạn đang sử dụng đã bị xóa bởi một quá trình bên ngoài khác, v.v.). Dịch vụ web thậm chí có thể được xác nhận trước khi kết nối được thử, nhưng trong quá trình truyền dữ liệu đã xảy ra sự cố.
Trong kịch bản đó, không có gì mà bạn hoặc đồng nghiệp của bạn có thể làm để giúp đỡ nó. Nhưng bạn vẫn phải làm một cái gì đó và không để ứng dụng chỉ chết và biến mất trong mắt người dùng. Bạn sử dụng một ngoại lệ được kiểm tra cho điều đó và xử lý ngoại lệ đó, bạn có thể làm gì khi điều đó xảy ra?, Hầu hết thời gian, chỉ để cố gắng ghi lại lỗi, có thể lưu công việc của bạn (ứng dụng hoạt động) và gửi thông báo cho người dùng . (Trang web blabla không hoạt động, vui lòng thử lại sau, v.v.)
Nếu ngoại lệ được kiểm tra bị lạm dụng (bằng cách thêm "ngoại lệ ném" vào tất cả các chữ ký phương thức), thì mã của bạn sẽ trở nên rất dễ hỏng, bởi vì mọi người sẽ bỏ qua ngoại lệ đó (vì quá chung chung) và chất lượng mã sẽ nghiêm trọng thỏa hiệp.
Nếu bạn lạm dụng ngoại lệ không được kiểm tra, một cái gì đó tương tự sẽ xảy ra. Những người sử dụng mã đó không biết liệu có điều gì đó có thể sai hay không, rất nhiều lần thử {...} bắt (Ném được t) sẽ xuất hiện.