คุณถูกต้อง
ข้อยกเว้นที่ไม่ได้ตรวจสอบใช้เพื่อให้ระบบล้มเหลวอย่างรวดเร็วซึ่งเป็นสิ่งที่ดี คุณควรระบุอย่างชัดเจนว่าวิธีการของคุณคาดหวังอะไรเพื่อให้ทำงานได้อย่างถูกต้อง วิธีนี้คุณสามารถตรวจสอบอินพุตได้เพียงครั้งเดียว
ตัวอย่างเช่น
/**
* @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"
.....
}
เพียงแค่ใส่ตัวอย่าง ประเด็นคือถ้าระบบล้มเหลวอย่างรวดเร็วคุณจะรู้ได้ว่าที่ไหนและเพราะเหตุใดระบบจึงล้มเหลว คุณจะได้รับ stacktrace เช่น:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
และคุณจะรู้ว่าเกิดอะไรขึ้น OtherClass ในเมธอด "delegateTheWork" (ที่บรรทัด 4569) เรียกคลาสของคุณด้วยค่า "exit" แม้ว่าจะไม่ควรเป็นต้น
มิฉะนั้นคุณต้องโรยการตรวจสอบความถูกต้องให้ทั่วรหัสของคุณ นอกจากนี้บางครั้งก็ยากที่จะติดตามสิ่งที่ผิดพลาดและคุณอาจคาดหวังว่าจะมีการดีบักนานหลายชั่วโมง
สิ่งเดียวกันเกิดขึ้นกับ NullPointerExceptions หากคุณมีคลาส 700 บรรทัดที่มี 15 เมธอดบางตัวที่ใช้ 30 แอ็ตทริบิวต์และไม่มีวิธีใดที่สามารถเป็นโมฆะได้แทนการตรวจสอบความถูกต้องในแต่ละวิธีเพื่อความเป็นโมฆะคุณสามารถทำให้คุณสมบัติทั้งหมดเป็นแบบอ่านอย่างเดียว วิธีการโรงงาน
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
....
}
การตรวจสอบข้อยกเว้นมีประโยชน์เมื่อโปรแกรมเมอร์ (คุณหรือเพื่อนร่วมงานของคุณ) ทำทุกอย่างถูกต้องตรวจสอบอินพุตทดสอบการทำงานและรหัสทั้งหมดนั้นสมบูรณ์แบบ แต่รหัสนั้นเชื่อมต่อกับเว็บเซอร์ของบุคคลที่สามซึ่งอาจลง (หรือไฟล์ คุณใช้ถูกลบโดยกระบวนการภายนอกอื่น ๆ ) เว็บเซอร์อาจทำการตรวจสอบก่อนที่จะพยายามเชื่อมต่อ แต่ในระหว่างการถ่ายโอนข้อมูลมีบางอย่างผิดปกติ
ในสถานการณ์นั้นไม่มีอะไรที่คุณหรือเพื่อนร่วมงานของคุณสามารถทำได้เพื่อช่วยมัน แต่คุณยังต้องทำอะไรและอย่าปล่อยให้แอปพลิเคชันตายและหายไปในสายตาของผู้ใช้ คุณใช้ข้อยกเว้นที่ตรวจสอบแล้วและจัดการกับข้อยกเว้นสิ่งที่คุณสามารถทำได้เมื่อสิ่งนั้นเกิดขึ้นส่วนใหญ่เพียงพยายามบันทึกข้อผิดพลาดอาจบันทึกงานของคุณ (แอปทำงาน) และแสดงข้อความถึงผู้ใช้ . (เว็บไซต์ blabla ไม่ทำงานโปรดลองอีกครั้งในภายหลังและอื่น ๆ )
หากข้อยกเว้นที่ตรวจสอบมีการใช้มากเกินไป (โดยการเพิ่ม "ข้อยกเว้นการส่ง" ในลายเซ็นวิธีการทั้งหมด) รหัสของคุณจะบอบบางมากเพราะทุกคนจะเพิกเฉยต่อข้อยกเว้นนั้น (เพราะกว้างเกินไป) และคุณภาพของรหัสจะรุนแรง ที่ถูกบุกรุก
หากคุณใช้ข้อยกเว้นที่ไม่ได้ตรวจสอบมากเกินไปสิ่งที่คล้ายกันจะเกิดขึ้น ผู้ใช้รหัสนั้นไม่ทราบว่ามีบางอย่างผิดปกติลอง {... } catch (Throwable t) ได้มากจะปรากฏขึ้น