การใช้การจัดการ ความผิดพลาด (Exception Handler) มีข้อควรระวัง โดยเฉพาะอย่างยิ่ง การส่งข้อผิดพลาดต่างๆ ออกมาข้อแนะนำคือ ให้สร้างโครงสร้างเพื่อจัดการข้อผิดพลาด ขึ้นภายในแอพพลิเคชั่นของเรา แต่จะต้องออกแบบ ให้หลีกเลี่ยง การทำงาน ที่วิ่งเข้าไปภายในตัวจัดการข้อผิดพลาด เรื่องนี้สามารถเข้าใจได้ไม่ยาก ยกเว้นแต่เฉพาะนักพัฒนาผู้ใช้การ เขียนโค้ดขึ้นเอง อย่างเช่น การใช้ ASP รุ่นก่อน ใช้การเขียนโค้ดขึ้นเอง บ่อยครั้งมักใช้ การวางบล็อก คำสั่ง On Error Resume Next ที่ยินยอมให้โค้ด ประมวลผลคำสั่งอย่างต่อเนื่องผ่าน ค่าความผิดพลาด ไปแล้วค่อยมาตรวจสอบค่าผิดพลาดของผลลัพธ์ที่กำหนดไว้ในภายหลัง ซึ่งวิธีการนี้ ไม่ได้นำมาใช้ใน สภาพแวดล้อมการทำงานของ .NET ฉะนั้นควรออกแบบโค้ด ให้ใช้ตัวจัดการ ข้อผิดพลาด เป็นทางเลือกสุดท้าย โดยพิจารณา ค่าความผิดพลาดต่างๆ และตรวจสอบประเภทของฟังก์ชั่น เพื่อดักจับ ข้อผิดพลาดเหล่านั้น ก่อนที่จะทำการแปลคำสั่ง เท่ากับบังคับให้เรา แสดงข้อผิดพลาดในช่วงเวลาประมวลผล (runtime) ออกมา
การส่งข้อผิดพลาด เฉพาะกรณีที่จำเป็นจริงๆ เท่านั้น เนื่องจาก มันจะเป็นการทำงานที่สร้างภาระให้เรามาก (ในมุมมองการ ใช้ทรัพยากร การตรวจสอบโค้ดเพื่อแก้ไข ประสิทธิผลการทำงาน ฯลฯ) คลาส exception ได้จัดหา รายละเอียดต่างๆ มากมาย ที่ใช้ได้ โดยไม่ต้องใช้อาศัย การเรียกทำงานจากโค้ด ที่จะรับค่าที่ส่งข้อผิดพลาดออกมา ในกรณีนี้ จะเป็นการดีกว่า ที่จะแสดง ข้อผิดพลาดที่กำหนดขึ้นเอง โดยการใช้ Err.Raise แทนที่จะโยนไปให้ ตัดจัดการข้อผิดพลาด จัดการให้ การทำงานนี้ จะแปลงรายละเอียดข้อผิดพลาดพื้นฐาน อย่างเช่น หมายเลขข้อผิดพลาด แหล่งกำเนิด และข้อความ แต่มันจะหลีกเหลี่ยงรายละเอียดที่ซับซ้อน อย่างเช่น รายละเอียดของ Call stackท้ายนี้ ให้เราเตรียม ชุดคำสั่ง Catch หลายๆ ตัวพร้อมกับ รายการกรองเงื่อนไขต่างๆ จากนั้นจัดเรียงให้ ข้อกำหนดที่เกิดขึ้นบ่อยๆ เป็นค่าแรกที่โปแกรมจะตรวจพบ ดังแสดงตามตัวอย่าง
Try
Catch SqlErr as SqlException
Catch err As Exception
Finally
End Try
ไม่มีความคิดเห็น:
แสดงความคิดเห็น