คำถามติดแท็ก checked-exceptions

Joshua Bloch ใน " Effective Java " กล่าวว่า ใช้ข้อยกเว้นที่ตรวจสอบแล้วสำหรับเงื่อนไขที่สามารถกู้คืนได้และข้อยกเว้นรันไทม์สำหรับข้อผิดพลาดในการเขียนโปรแกรม (รายการ 58 ในรุ่นที่ 2) ลองดูว่าฉันเข้าใจสิ่งนี้ถูกต้องหรือไม่ นี่คือความเข้าใจของฉันเกี่ยวกับข้อยกเว้นที่ตรวจสอบ: try{ String userInput = //read in user input Long id = Long.parseLong(userInput); }catch(NumberFormatException e){ id = 0; //recover the situation by setting the id to 0 } 1. ข้างต้นถือว่าเป็นข้อยกเว้นที่ตรวจสอบหรือไม่ 2. RuntimeException เป็นข้อยกเว้นที่ไม่ได้ตรวจสอบหรือไม่? นี่คือความเข้าใจของฉันเกี่ยวกับข้อยกเว้นที่ไม่ได้ตรวจสอบ: try{ File …

703 java  exception  runtimeexception  checked-exceptions  unchecked-exception 

เป็นเวลาหลายปีแล้วที่ฉันไม่สามารถรับคำตอบที่เหมาะสมสำหรับคำถามต่อไปนี้: เหตุใดนักพัฒนาซอฟต์แวร์บางคนจึงต่อต้านข้อยกเว้นที่ตรวจสอบ ฉันมีการสนทนามากมายอ่านสิ่งต่าง ๆ บนบล็อกอ่านสิ่งที่ Bruce Eckel ต้องพูด (คนแรกที่ฉันเห็นพูดต่อต้านพวกเขา) ขณะนี้ฉันกำลังเขียนโค้ดใหม่และให้ความสนใจอย่างระมัดระวังกับวิธีที่ฉันจัดการกับข้อยกเว้น ฉันพยายามที่จะเห็นมุมมองของฝูงชน "เราไม่ชอบการตรวจสอบข้อยกเว้น" และฉันก็ยังไม่เห็น ทุกบทสนทนาที่ฉันจบลงด้วยคำถามเดียวกันที่ยังไม่ได้รับคำตอบขอให้ฉันตั้งค่า: โดยทั่วไป (จากวิธีการออกแบบ Java) Error สำหรับสิ่งที่ไม่ควรถูกจับ (VM มีอาการแพ้ถั่วลิสงและมีคนทิ้งขวดถั่วลิสงลงไป) RuntimeException สำหรับสิ่งที่โปรแกรมเมอร์ทำผิด (โปรแกรมเมอร์เดินจากจุดสิ้นสุดของอาร์เรย์) Exception(ยกเว้นRuntimeException) สำหรับสิ่งที่อยู่นอกเหนือการควบคุมของโปรแกรมเมอร์ (ดิสก์เต็มในขณะที่เขียนไปยังระบบไฟล์มีการ จำกัด การจัดการไฟล์สำหรับกระบวนการแล้วและคุณไม่สามารถเปิดไฟล์ได้อีก) Throwable เป็นเพียงพาเรนต์ของชนิดข้อยกเว้นทั้งหมด อาร์กิวเมนต์ทั่วไปที่ฉันได้ยินคือถ้ามีข้อยกเว้นเกิดขึ้นจากนั้นนักพัฒนาทั้งหมดจะต้องทำคือออกจากโปรแกรม อาร์กิวเมนต์ที่พบบ่อยอีกข้อที่ฉันได้ยินคือการยกเว้นการตรวจสอบทำให้ยากต่อการกำหนดรหัสซ้ำ สำหรับอาร์กิวเมนต์ "สิ่งที่ฉันต้องทำคือออก" ฉันบอกว่าแม้ว่าคุณจะออกจากคุณต้องแสดงข้อความแสดงข้อผิดพลาดที่สมเหตุสมผล หากคุณเพียงแค่ลงโทษในการจัดการข้อผิดพลาดผู้ใช้ของคุณจะไม่มีความสุขมากเกินไปเมื่อโปรแกรมออกโดยไม่ระบุสาเหตุที่ชัดเจน สำหรับกลุ่ม "ทำให้ยากที่จะสร้างใหม่" ซึ่งบ่งชี้ว่าไม่ได้เลือกระดับที่เหมาะสมของสิ่งที่เป็นนามธรรม แทนที่จะประกาศวิธีการพ่นIOExceptionที่IOExceptionควรจะเปลี่ยนเป็นข้อยกเว้นที่เหมาะสมมากขึ้นสำหรับสิ่งที่เกิดขึ้นใน ฉันไม่มีปัญหาในการตัด Main ด้วยcatch(Exception)(หรือในบางกรณีcatch(Throwable)เพื่อให้แน่ใจว่าโปรแกรมสามารถออกจากระบบได้อย่างงดงาม - แต่ฉันมักจะจับข้อยกเว้นเฉพาะที่จำเป็นต้องใช้การทำเช่นนั้นทำให้ฉันสามารถแสดงที่เหมาะสมอย่างน้อยที่สุด ข้อความผิดพลาด. คำถามที่ผู้คนไม่เคยตอบคือ: หากคุณโยนRuntimeException คลาสย่อยแทนที่จะเป็นException …

456 java  exception  checked-exceptions 

ฉันจะโยนข้อยกเว้นตรวจสอบจากภายใน Java 8 สตรีม / lambdas ได้อย่างไร กล่าวอีกนัยหนึ่งฉันต้องการสร้างรหัสเช่นคอมไพล์นี้: public List<Class> getClasses() throws ClassNotFoundException { List<Class> classes = Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String") .map(className -> Class.forName(className)) .collect(Collectors.toList()); return classes; } รหัสนี้ไม่ได้รวบรวมเนื่องจากClass.forName()วิธีการดังกล่าวข้างต้นพ่นClassNotFoundExceptionซึ่งมีการตรวจสอบ โปรดทราบฉันไม่ต้องการห่อข้อยกเว้นที่ตรวจสอบภายในข้อยกเว้นรันไทม์และโยนข้อยกเว้นที่ไม่ได้ตรวจสอบและแทนที่ ฉันต้องการที่จะโยนข้อยกเว้นการตรวจสอบตัวเองและไม่เพิ่มน่าเกลียดtry/ catchesกับกระแส

287 java  lambda  java-8  java-stream  checked-exceptions 

ใน Java (หรือภาษาอื่นที่มีข้อยกเว้นที่ตรวจสอบแล้ว) เมื่อสร้างคลาสยกเว้นของคุณเองคุณจะตัดสินใจได้อย่างไรว่าควรตรวจสอบหรือไม่เลือก สัญชาตญาณของฉันคือการพูดว่าจะมีการเรียกข้อยกเว้นที่ถูกตรวจสอบในกรณีที่ผู้โทรอาจสามารถกู้คืนได้อย่างมีประสิทธิผลในกรณีที่ข้อยกเว้นที่ไม่ได้ตรวจสอบจะมีมากขึ้นสำหรับกรณีที่ไม่สามารถกู้คืนได้

213 java  exception  checked-exceptions 

class throwseg1 { void show() throws Exception { throw new Exception("my.own.Exception"); } void show2() throws Exception // Why throws is necessary here ? { show(); } void show3() throws Exception // Why throws is necessary here ? { show2(); } public static void main(String s[]) throws Exception // Why throws …

102 java  exception-handling  unhandled-exception  throws  checked-exceptions