JavaRush /จาวาบล็อก /Random-TH /ข้อผิดพลาดทั่วไปในการจัดการข้อยกเว้น
Ve4niY
ระดับ

ข้อผิดพลาดทั่วไปในการจัดการข้อยกเว้น

เผยแพร่ในกลุ่ม
ข้อยกเว้นคือการหยุดชะงักของการดำเนินการตามปกติของโปรแกรม Java (หรืออื่นๆ) การละเมิดนี้อาจเกิดขึ้นได้เนื่องจากการละเมิดการเข้าถึงหน่วยความจำ การหารด้วยศูนย์ ปัญหาในการเริ่มต้น การดำเนินการตามคำสั่งที่ผิดกฎหมาย หรือข้อผิดพลาดร้ายแรงอื่นๆ Java สามารถจัดการสถานการณ์ที่ไม่พึงประสงค์ทั้งหมดได้อย่างสวยงาม แต่เมื่อต้องใช้คุณสมบัติ Java เหล่านี้โดยนักพัฒนา อาจเกิดปัญหาหลายประการ ในบทความนี้ ฉันจะไม่พูดถึงวิธีการทำงานของ Exception Handling ใน Java ฉันคิดว่าผู้อ่านคุ้นเคยกับลำดับชั้นของข้อยกเว้น, ข้อยกเว้นที่ตรวจสอบแล้ว, ข้อยกเว้นที่ไม่ได้ตรวจสอบและข้อยกเว้นรันไทม์ ที่นี่เราจะพูดถึงข้อผิดพลาดทั่วไปที่คุณควรหลีกเลี่ยง
ผู้มีส่วนได้ส่วนเสียในข้อยกเว้น
เมื่อใดก็ตามที่เธรดการดำเนินการถูกขัดจังหวะ ข้อมูลเกี่ยวกับเธรดจะต้องถูกส่งกลับไปยังผู้ดำเนินการโปรแกรม เธรดนี้สามารถเริ่มต้นจากหน้าจอ จากงานแบตช์ หรือด้วยวิธีอื่นใด ทริกเกอร์ทั้งหมดนี้รอให้มีการละเมิดบางอย่างในโฟลว์เพื่อส่งข้อความในรูปแบบใดรูปแบบหนึ่ง ทริกเกอร์ตามหน้าจอสามารถแจ้งให้เราทราบอย่างอ่อนโยนว่ามีปัญหาทางเทคนิคบางประการ และเราควรติดต่อฝ่ายสนับสนุนเพื่อขอความช่วยเหลือและคำแนะนำ กระบวนการแบบแบตช์หรือโปรแกรม Java แบบสแตนด์อโลนอาจคาดหวังให้รายงานข้อผิดพลาดปรากฏในรูปแบบของบันทึกบางประเภทที่ผู้ใช้ปลายทางไม่สามารถเข้าใจได้อย่างสมบูรณ์ แต่นักธุรกิจจำเป็นต้องได้รับข้อความในภาษาที่พวกเขาเข้าใจ NullPointerException ที่น่ากลัวในใจของผู้ใช้นั้นน่ารำคาญมาก บางครั้งข้อผิดพลาดเหล่านี้เป็นผลมาจากการใช้โปรแกรมอย่างไม่ถูกต้อง แต่บางครั้งก็เป็นปัญหาที่ต้องแก้ไข ผู้มีส่วนได้ส่วนเสียที่สำคัญอันดับสองคือบุคคลที่จะต้องจัดการกับปัญหาที่เกิดจากข้อยกเว้น บุคคลนี้ไม่สามารถสังเกตการดำเนินการจริงของโปรแกรมได้เมื่อมีข้อยกเว้นเกิดขึ้น โดยจะขึ้นอยู่กับสองสิ่ง - ประการแรก ข้อมูลที่ผู้ใช้ให้มาซึ่งมีปัญหา และประการที่สอง บันทึกบางประเภทที่สร้างขึ้นเมื่อมีข้อยกเว้นเกิดขึ้น นอกจากนี้ผู้ที่จะวิเคราะห์ปัญหาไม่ใช่คนเดียวกับผู้เขียนโปรแกรม ดังนั้น ผู้พัฒนาโปรแกรมจึงต้องให้ข้อมูลที่เพียงพอสำหรับการวิเคราะห์ วิธีเดียวในการสื่อสารระหว่างผู้พัฒนาโปรแกรมและดีบักเกอร์คือบันทึก นอกจากนี้ บางครั้งเนื่องจากเหตุผลด้านความปลอดภัย บางครั้งบันทึกบันทึกอาจไม่ประกอบด้วยรายละเอียดจริงทั้งหมดของการทำงานของโปรแกรมเมื่อมีข้อยกเว้นเกิดขึ้น ลองดูข้อผิดพลาดที่อาจเกิดขึ้นในการจัดการข้อยกเว้น บางคนดูโง่มาก แต่ก็มีคนอยู่ ที่ไม่ใส่ใจจนเกิดข้อผิดพลาดจนเกิดปัญหา
บล็อกข้อยกเว้นว่างเปล่า
นี่เป็นหนึ่งในข้อผิดพลาดที่ไม่พึงประสงค์มากที่สุดในการจัดการข้อยกเว้น ในกรณีนี้ ข้อยกเว้นจะถูกละเว้น โซลูชันไม่มีอะไรนอกจากบรรทัดความคิดเห็นเพื่อยกเว้นข้อยกเว้น try{ }catch(SQLException sqe){ // do nothing } ในบางกรณีที่เกิดขึ้นไม่บ่อยนัก เช่น ในบล็อกสุดท้ายเมื่อฐานข้อมูลถูกปิด อาจมีข้อยกเว้นเกิดขึ้น ในกรณีนี้สามารถละเลยได้ try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }
ลักษณะทั่วไปของข้อความแสดงข้อยกเว้นไม่ถูกต้อง
จุดนี้เป็นเรื่องส่วนตัว หลังจากตรวจพบข้อยกเว้นแล้ว คุณสามารถรายงานไปยังผู้ใช้ปลายทางในรูปแบบของข้อความที่เป็นมิตร ค่อนข้างเป็นไปได้ที่รายละเอียดของข้อความต้นฉบับจะหายไปเมื่อข้อความต้นฉบับถูกแปลงเป็นข้อความทั่วไปข้อความเดียว ข้อความควรสื่อข้อมูลที่เหมาะสมแก่ผู้ใช้ เพื่อว่าเมื่อติดต่อทีมสนับสนุน ผู้ใช้เพียงเข้าสู่ระบบในบันทึกที่เหมาะสมเพื่อให้ข้อมูลเท่านั้น try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } ในแอปพลิเคชันแบบหลายชั้น แต่ละเลเยอร์จะจับข้อยกเว้นและส่งข้อยกเว้นประเภทใหม่ บางครั้งจำเป็นอย่างยิ่งที่จะต้องมีข้อยกเว้นบางประเภท: - Data Access Layer -> สร้าง DataAccessException - Business Implementation Layer -> สร้าง BusinessException - Application Service Layer -> สร้าง ApplicationServiceException ทุกอย่างดูสมเหตุสมผลใช่ไหม ที่นี่เราอาจต้องเลือกระหว่าง ApplicationServiceException และ BusinessException เนื่องจากทั้งสองสามารถแสดงข้อมูลเดียวกันได้ การแปลงข้อยกเว้นอย่างใดอย่างหนึ่งเหล่านี้ดูเหมือนไม่จำเป็น
ทำลายคลาส StackTrace
ในระหว่างกระบวนการเปลี่ยนข้อยกเว้นเป็นประเภทพิเศษใหม่ การติดตามสแต็กอาจหายไป ทำให้การติดตามสาเหตุที่แท้จริงของข้อยกเว้นนั้นเหมือนฝันร้าย ในโค้ดด้านล่างนี้ คุณสามารถดูได้ว่าข้อยกเว้นใหม่เกิดขึ้นอย่างไรโดยไม่ได้รับข้อมูลใดๆ จากข้อยกเว้นเดิม try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }
เขียนทับเหตุผลข้อยกเว้น
ข้อความยกเว้นแต่ละข้อความประกอบด้วยข้อมูลเกี่ยวกับเหตุผลของการยกเว้น อย่างไรก็ตาม เมื่อมีการสร้างข้อยกเว้นใหม่ ข้อมูลเกี่ยวกับข้อยกเว้นเก่าอาจถูกลบอย่างถาวร สิ่งนี้คล้ายกับตัวอย่างด้านบนที่ StackTrace อาจถูกลบออกเนื่องจากมีข้อยกเว้นใหม่เกิดขึ้น
ไม่มีการค้นหาข้อยกเว้นเฉพาะ
บางครั้งนักพัฒนาก็ชอบที่จะเล่นอย่างปลอดภัยเมื่อจัดการกับข้อยกเว้น บางครั้งนี่เป็นเรื่องง่ายที่จะทำ แต่การจับ java.lang.Exception แทนที่จะเป็นข้อยกเว้นเฉพาะนั้นไม่เป็นที่ยอมรับ try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }
จับแล้วโยนโดยไม่จำเป็น
จับข้อยกเว้นถ้าคุณต้องการแปลงเป็นประเภทอื่น หรือช่วยให้คุณเพิ่มข้อมูลบางอย่างลงในข้อความแสดงข้อยกเว้นถึงผู้ใช้ปลายทางหรือนักวิเคราะห์ได้ มิฉะนั้นให้โยนพวกมันออกไปอีกในลายเซ็นวิธีการ (โดยใช้การขว้าง) แทนที่จะจับพวกมัน
กำลังจับ RuntimeException
ฉันอยากจะแนะนำให้หลีกเลี่ยงการจับ RuntimeException เป็นการดีกว่าที่จะจับข้อยกเว้นเฉพาะและปฏิบัติต่อพวกเขาแทน
ค้นหาข้อยกเว้นที่ไม่ได้ตรวจสอบ
เป็นหัวข้อที่ถกเถียงกันว่าจะจับข้อยกเว้นที่ไม่ได้ตรวจสอบหรือไม่ NullPointerException และ ArrayIndexOutOfBound อาจเป็นตัวอย่างที่ดีที่สุดของข้อยกเว้นที่ไม่ได้ตรวจสอบ แทนที่จะจับข้อยกเว้นเหล่านี้ คุณสามารถเปลี่ยนรหัสของคุณเพื่อจัดการกับสถานการณ์เหล่านี้ได้ ตัวอย่างเช่น เพื่อหลีกเลี่ยง NullPointerException เพื่อให้แน่ใจว่าตัวแปรทั้งหมดได้รับการเตรียมใช้งาน เพื่อหลีกเลี่ยงข้อยกเว้น ArrayIndexOutOfBound เพื่อกำหนดอาร์เรย์ที่มีความยาวที่ถูกต้อง เป็นต้น
ปัญหาที่เกี่ยวข้องกับการบันทึกข้อยกเว้น
นิตยสารจะช่วยเหลือผู้สนใจคนที่สอง ซึ่งก็คือบุคคลที่วิเคราะห์ปัญหา บางครั้งนักพัฒนาใช้ไฟล์บันทึกมากเกินไปและมีการสร้างบันทึกในทุกระดับของแอปพลิเคชัน บันทึกควรบันทึกข้อยกเว้นในระดับที่เกิดขึ้น ดูเหมือนว่าเหมาะสมที่สุดที่จะแสดงคำเตือนว่ามีข้อยกเว้นเกิดขึ้น พร้อมข้อเสนอให้หยุดหรือดำเนินการเรียกใช้โปรแกรมต่อไป และบังคับให้บันทึกข้อยกเว้นในบันทึก
ข้อยกเว้นการควบคุมการไหล
ข้อยกเว้นคือการขัดขวางโฟลว์ปกติของโปรแกรม ซึ่งหมายความว่าคุณต้องขัดจังหวะโฟลว์นี้และแจ้งให้ผู้ใช้ทราบ หากเราเพิ่มการเรียกเมธอดที่เป็นเธรดสำรอง จะทำให้เกิดปัญหาการบำรุงรักษาอย่างมาก try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }
การใช้งาน java.lang.Exception แพร่หลาย
ไม่ใช่ความคิดที่ดีที่จะใช้ java.lang.Exception ทุกที่สำหรับข้อยกเว้นใดๆ ควรใช้ข้อยกเว้นเฉพาะแอปพลิเคชันหรือข้อยกเว้น Java มาตรฐานที่เหมาะสมที่สุดแทน บทความต้นฉบับ: ข้อผิดพลาดทั่วไปในการจัดการข้อยกเว้น แปลและพากย์เสียงโดย: Ve4niY
ความคิดเห็น
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION