วิธีการเขียนข้อความยกเว้นที่ดี

ขณะนี้ฉันกำลังทำการตรวจสอบโค้ดและหนึ่งในสิ่งที่ฉันสังเกตเห็นคือจำนวนข้อยกเว้นที่ดูเหมือนว่าข้อความข้อยกเว้นจะย้ำตำแหน่งข้อยกเว้นที่เกิดขึ้น เช่น

throw new Exception("BulletListControl: CreateChildControls failed.");

ทั้งสามรายการในข้อความนี้ฉันสามารถทำงานได้จากข้อยกเว้นที่เหลือ ฉันรู้ชั้นเรียนและวิธีการจากการติดตามสแต็กและฉันรู้ว่ามันล้มเหลว (เพราะฉันมีข้อยกเว้น)

ฉันทำให้ฉันคิดถึงข้อความที่ฉันใส่ไว้ในข้อความยกเว้น ก่อนอื่นฉันสร้างคลาสยกเว้นถ้าไม่มีอยู่แล้วด้วยเหตุผลทั่วไป (เช่นPropertyNotFoundException- สาเหตุ ) จากนั้นเมื่อฉันโยนมันข้อความจะระบุสิ่งที่ผิดพลาด (เช่น "ไม่สามารถหาคุณสมบัติ 'IDontExist' บนโหนด 1234 "- อะไร ) StackTraceที่อยู่ใน เมื่ออาจจะจบลงในบันทึก (ถ้ามี) วิธีสำหรับนักพัฒนาที่จะทำงานออก (และแก้ไข)

คุณมีเคล็ดลับอื่น ๆ ในการขว้างข้อยกเว้นหรือไม่? โดยเฉพาะเกี่ยวกับการสร้างชนิดใหม่และข้อความข้อยกเว้น

ฉันจะส่งคำตอบของฉันไปยังสิ่งที่เกิดขึ้นภายหลังจากข้อยกเว้น: มันดีสำหรับอะไรและซอฟต์แวร์ควรทำอย่างไรผู้ใช้ของคุณควรทำอย่างไรกับข้อยกเว้น เทคนิคที่ยอดเยี่ยมที่ฉันได้พบในช่วงต้นอาชีพของฉันคือการรายงานปัญหาและข้อผิดพลาดใน 3 ส่วน ได้แก่ บริบทปัญหาและวิธีแก้ไข การใช้ข้อผิดพลาดนี้ทำให้เกิดข้อผิดพลาดในการจัดการอย่างมากมายและทำให้ซอฟต์แวร์ดีขึ้นอย่างมากสำหรับผู้ใช้งาน

นี่คือตัวอย่างเล็ก ๆ น้อย ๆ

Context: Saving connection pooling configuration changes to disk.
Problem: Write permission denied on file '/xxx/yyy'.
Solution: Grant write permission to the file.

ในกรณีนี้ผู้ประกอบการรู้ว่าจะทำอย่างไรและไฟล์ใดที่จะต้องได้รับผลกระทบ พวกเขายังรู้ว่าการเปลี่ยนแปลงการรวมการเชื่อมต่อไม่ได้ทำและควรทำซ้ำ

Context: Sending email to 'abc@xyz.com' regarding 'Blah'.
Problem: SMTP connection refused by server 'mail.xyz.com'.
Solution: Contact the mail server administrator to report a service problem.  The email will be sent later. You may want to tell 'abc@xyz.com' about this problem.

ฉันเขียนระบบฝั่งเซิร์ฟเวอร์และผู้ให้บริการของฉันมักจะรองรับบรรทัดแรกที่เข้าใจเทคโนโลยี ฉันจะเขียนข้อความต่างกันสำหรับซอฟต์แวร์เดสก์ท็อปที่มีผู้ชมต่างกัน แต่รวมถึงข้อมูลเดียวกัน

มีสิ่งมหัศจรรย์เกิดขึ้นมากมายหากใช้เทคนิคนี้ นักพัฒนาซอฟต์แวร์มักจะถูกวางไว้ที่ดีที่สุดในการรู้วิธีการแก้ปัญหาในรหัสของตัวเองดังนั้นการเข้ารหัสการแก้ปัญหาด้วยวิธีนี้ในขณะที่คุณเขียนรหัสเป็นประโยชน์อย่างมากสำหรับผู้ใช้ปลายทางที่เสียเปรียบในการค้นหาวิธีแก้ปัญหา ซอฟต์แวร์กำลังทำอะไรอยู่ ทุกคนที่เคยอ่านข้อความแสดงข้อผิดพลาดของ Oracle จะรู้ว่าฉันหมายถึงอะไร

สิ่งมหัศจรรย์ที่สองที่นึกถึงคือเมื่อคุณพบว่าตัวเองพยายามอธิบายวิธีการแก้ปัญหาในข้อยกเว้นของคุณและคุณกำลังเขียน "ตรวจสอบ X และถ้า A แล้ว B อื่น C" นี่เป็นสัญญาณที่ชัดเจนและชัดเจนว่ามีการตรวจสอบข้อยกเว้นของคุณในสถานที่ที่ไม่ถูกต้อง โปรแกรมเมอร์คุณมีความสามารถในการเปรียบเทียบสิ่งต่าง ๆ ในรหัสดังนั้น"ถ้า"คำสั่งควรจะทำงานในรหัสทำไมเกี่ยวข้องกับผู้ใช้ในสิ่งที่สามารถอัตโนมัติ? โอกาสที่จะเป็นจากลึกลงไปในรหัสและใครบางคนได้ทำสิ่งที่ขี้เกียจและโยน IOException จากจำนวนของวิธีการใด ๆ และจับข้อผิดพลาดที่อาจเกิดขึ้นจากทั้งหมดของพวกเขาในการป้องกันการเรียกรหัสที่ไม่สามารถเพียงพออธิบายสิ่งที่ผิดพลาดสิ่งที่เฉพาะเจาะจงบริบทคือและวิธีแก้ไข สิ่งนี้กระตุ้นให้คุณเขียนข้อผิดพลาดที่ละเอียดกว่าของธัญพืชจับและจัดการข้อผิดพลาดเหล่านั้นในที่ที่ถูกต้องในโค้ดของคุณเพื่อให้คุณสามารถสื่อสารได้อย่างถูกต้องตามขั้นตอนที่ผู้ปฏิบัติงานควรทำ

ที่ บริษัท แห่งหนึ่งเรามีผู้ให้บริการชั้นแนวหน้าที่รู้จักซอฟต์แวร์ดีมากและรักษา "run book" ของตนเองซึ่งช่วยเพิ่มการรายงานข้อผิดพลาดและแนวทางแก้ไขที่แนะนำ เมื่อต้องการรับรู้นี้ซอฟต์แวร์เริ่มต้นรวมถึงการเชื่อมโยง wiki ไปยังหนังสือที่ทำงานในข้อยกเว้นเพื่อให้คำอธิบายพื้นฐานพร้อมใช้งานเช่นเดียวกับการเชื่อมโยงไปยังการอภิปรายและการสังเกตขั้นสูงโดยผู้ประกอบการเมื่อเวลาผ่านไป

หากคุณมีผู้มีส่วนร่วมในการลองใช้เทคนิคนี้จะเห็นได้ชัดว่าคุณควรตั้งชื่อข้อยกเว้นเป็นรหัสเมื่อสร้างของคุณเอง NonRecoverableConfigurationReadFailedExceptionจะกลายเป็นเรื่องย่อสำหรับสิ่งที่คุณกำลังจะอธิบายให้ผู้ประกอบการได้อย่างเต็มที่ ฉันชอบที่จะ verbose และฉันคิดว่ามันจะง่ายขึ้นสำหรับนักพัฒนาคนต่อไปที่แตะรหัสของฉันเพื่อตีความ

ในคำถามล่าสุดนี้ฉันได้ชี้ให้เห็นว่าข้อยกเว้นไม่ควรมีข้อความเลย ในความเห็นของฉันความจริงที่ว่าพวกเขาทำนั้นเป็นความเข้าใจผิดอย่างใหญ่หลวง สิ่งที่ฉันเสนอก็คือ

"ข้อความ" ของข้อยกเว้นคือชื่อคลาส (มีคุณสมบัติครบถ้วน) ของข้อยกเว้น

ข้อยกเว้นควรมีตัวแปรภายในสมาชิกของตัวเองให้มากที่สุดเท่าที่จะเป็นไปได้เกี่ยวกับสิ่งที่เกิดขึ้น ตัวอย่างเช่นIndexOutOfRangeExceptionควรมีค่าดัชนีที่พบว่าไม่ถูกต้องเช่นเดียวกับค่าบนและล่างที่ถูกต้องในขณะที่ข้อยกเว้นถูกโยน ด้วยวิธีนี้คุณสามารถมีข้อความที่สร้างขึ้นโดยอัตโนมัติซึ่งอ่านเช่นนี้IndexOutOfRangeException: index = -1; min=0; max=5และสิ่งนี้พร้อมกับการติดตามสแต็กควรเป็นข้อมูลวัตถุประสงค์ทั้งหมดที่คุณต้องการเพื่อแก้ไขปัญหา การจัดรูปแบบให้เป็นข้อความที่สวยงามเช่น "ดัชนี -1 ไม่อยู่ระหว่าง 0 ถึง 5" จะไม่เพิ่มค่าใด ๆ

ในตัวอย่างเฉพาะของคุณNodePropertyNotFoundExceptionคลาสจะมีชื่อของคุณสมบัติที่ไม่พบและการอ้างอิงถึงโหนดที่ไม่มีคุณสมบัติ สิ่งนี้สำคัญ: มันไม่ควรมีชื่อของโหนด ควรมีการอ้างอิงไปยังโหนดจริง ในกรณีเฉพาะของคุณสิ่งนี้อาจไม่จำเป็น แต่เป็นเรื่องของหลักการและวิธีการคิดที่ต้องการ: ข้อกังวลหลักเมื่อสร้างข้อยกเว้นคือต้องใช้งานด้วยรหัสซึ่งอาจจับได้ การใช้งานโดยมนุษย์นั้นเป็นเรื่องสำคัญ แต่เป็นเรื่องรองเท่านั้น

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

แน่นอนเนื่องจากชื่อคลาสของข้อยกเว้นคือข้อความของข้อยกเว้น (และตัวแปรสมาชิกของข้อยกเว้นเป็นรายละเอียดเฉพาะ) ซึ่งหมายความว่าคุณต้องการข้อยกเว้นที่แตกต่างกันมากมายในการถ่ายทอดข้อความที่แตกต่างกันทั้งหมดและ นั่นเป็นเรื่องปกติ

ตอนนี้บางครั้งเมื่อเราเขียนโค้ดเราเจอสถานการณ์ที่ผิดพลาดซึ่งเราเพียงต้องการรหัสthrowคำสั่งอย่างรวดเร็วและดำเนินการเขียนรหัสของเราแทนที่จะต้องขัดจังหวะสิ่งที่เรากำลังทำเพื่อสร้างคลาสข้อยกเว้นใหม่เพื่อให้เราสามารถ โยนทิ้งไปตรงนั้น สำหรับกรณีเหล่านี้ฉันมีGenericExceptionคลาสที่จริง ๆ แล้วยอมรับข้อความสตริงเป็นพารามิเตอร์การสร้างเวลา แต่ตัวสร้างของคลาสข้อยกเว้นนี้ถูกประดับด้วยFIXME XXX TODOความคิดเห็นสีม่วงสดใสขนาดใหญ่ขนาดใหญ่ขนาดใหญ่ที่ระบุว่าการสร้างอินสแตนซ์ของคลาสนี้ทุกครั้ง แทนที่ด้วยอินสแตนซ์ของคลาสข้อยกเว้นพิเศษบางอย่างก่อนที่ระบบซอฟต์แวร์จะวางจำหน่ายโดยเฉพาะอย่างยิ่งก่อนที่รหัสจะถูกส่ง

ตามกฎทั่วไปข้อยกเว้นควรช่วยนักพัฒนาระบุสาเหตุโดยให้ข้อมูลที่เป็นประโยชน์ (ค่าที่คาดไว้ค่าจริงสาเหตุ / วิธีแก้ไขที่เป็นไปได้ ฯลฯ )

ประเภทยกเว้นใหม่ควรจะสร้างขึ้นเมื่อไม่มีในตัวชนิดทำให้ความรู้สึก ประเภทที่เฉพาะเจาะจงช่วยให้นักพัฒนาอื่น ๆ สามารถจับข้อยกเว้นและจัดการได้ หากนักพัฒนาซอฟต์แวร์รู้วิธีจัดการข้อยกเว้นของคุณ แต่เป็นประเภทExceptionเขาจะไม่สามารถจัดการได้อย่างถูกต้อง

ใน. NET ไม่เคยthrow new Exception("...")(เช่นผู้เขียนคำถามได้แสดง) การยกเว้นเป็นประเภทการยกเว้นหลักและไม่ควรถูกโยนทิ้งโดยตรง แทนที่จะโยนหนึ่งในประเภทข้อยกเว้น. NET ที่ได้รับมาหรือสร้างข้อยกเว้นที่กำหนดเองของคุณเองซึ่งได้มาจากข้อยกเว้น (หรือประเภทข้อยกเว้นอื่น)

ทำไมไม่โยนข้อยกเว้น? เพราะการโยนข้อยกเว้นไม่ได้ทำอะไรเลยเพื่ออธิบายข้อยกเว้นของคุณและบังคับให้รหัสการโทรของคุณเขียนโค้ดแบบcatch(Exception ex) { ... }ที่โดยทั่วไปจะไม่ดี :-)

สิ่งที่คุณต้องการค้นหาเพื่อ "เพิ่ม" ให้กับข้อยกเว้นคือองค์ประกอบของข้อมูลที่ไม่ได้มีอยู่ในข้อยกเว้นหรือการติดตามสแต็ก ไม่ว่าจะเป็นส่วนหนึ่งของ "ข้อความ" หรือจำเป็นต้องแนบเมื่อเข้าสู่ระบบเป็นคำถามที่น่าสนใจ

ตามที่คุณได้ระบุไว้แล้วข้อยกเว้นจะบอกคุณว่า stacktrace อาจบอกคุณว่าที่ไหน แต่ "ทำไม" อาจมีส่วนเกี่ยวข้องมากกว่า (ควรเป็นอย่างใดอย่างหนึ่งจะหวัง) กว่าแค่ไปหาเพื่อนที่บรรทัดหรือสองและพูดว่า " แน่นอน! " นี่เป็นเรื่องจริงมากขึ้นเมื่อบันทึกข้อผิดพลาดในรหัสการผลิต - ฉันมักถูกกัดด้วยข้อมูลที่ไม่ดีซึ่งพบว่ามันเข้าสู่ระบบจริงที่ไม่มีอยู่ในระบบทดสอบของเรา Somethig นั้นง่ายพอ ๆ กับการรู้ว่า ID คืออะไรของเร็กคอร์ดในฐานข้อมูลที่ทำให้เกิดข้อผิดพลาด (หรือร่วมให้ข้อมูล) สามารถประหยัดเวลาได้อย่างมาก

ดังนั้น ... ไม่ว่าจะเป็นในรายการหรือสำหรับ. NET จะถูกเพิ่มลงในการรวบรวมข้อมูลข้อยกเว้นที่บันทึกไว้ (cf @Plip!):

• พารามิเตอร์ (สิ่งนี้น่าสนใจนิดหน่อย - คุณไม่สามารถเพิ่มลงในการรวบรวมข้อมูลได้หากมันไม่ได้ทำให้เป็นอนุกรมและบางครั้งพารามิเตอร์เดียวอาจซับซ้อนอย่างน่าประหลาดใจ)
• ข้อมูลเพิ่มเติมที่ส่งคืนโดย ADO.NET หรือ Linq ไปยัง SQL หรือสิ่งที่คล้ายกัน (สิ่งนี้สามารถได้รับความน่าสนใจเล็กน้อย!)
• สิ่งอื่นใดอาจไม่ชัดเจน

แน่นอนว่าบางสิ่งคุณไม่ทราบว่าคุณต้องการจนกว่าคุณจะไม่ได้รับรายงาน / บันทึกข้อผิดพลาดครั้งแรก บางสิ่งที่คุณไม่ได้ตระหนักถึงคุณจะได้รับจนกว่าคุณจะพบว่าคุณต้องการ

สิ่งที่เป็นข้อยกเว้นสำหรับ ?

(1) การบอกผู้ใช้ว่ามีข้อผิดพลาดหรือไม่

นี่ควรเป็นทางเลือกสุดท้ายเนื่องจากรหัสของคุณควรมีการขอร้องและแสดงบางอย่าง "ดีกว่า" ยกเว้น

ข้อความ "ข้อผิดพลาด" ควรระบุอย่างชัดเจนและชัดเจนว่ามีอะไรผิดพลาดและอะไรถ้าผู้ใช้สามารถทำเพื่อกู้คืนจากเงื่อนไขข้อผิดพลาด

เช่น "โปรดอย่ากดปุ่มนี้อีก"

(2) บอกผู้พัฒนาเมื่อเกิดข้อผิดพลาด?

นี่คือประเภทของสิ่งที่คุณเข้าสู่ไฟล์สำหรับการวิเคราะห์ที่ตามมา
การติดตามสแต็กจะแจ้งให้ผู้พัฒนาทราบว่ารหัสใดบ้าง ข้อความควรจะระบุสิ่งที่ผิดพลาดอีกครั้ง

(3) การบอกตัวจัดการข้อยกเว้น (เช่นรหัส) ว่ามีบางอย่างผิดปกติหรือไม่

ประเภทของข้อยกเว้นจะตัดสินใจว่าจะดำเนินการยกเว้นจะได้รับที่จะมองมันและคุณสมบัติที่กำหนดไว้ในข้อยกเว้นวัตถุจะช่วยให้การจัดการจะจัดการกับมัน

ข้อความข้อยกเว้นคือไม่เกี่ยวข้องกันโดยสิ้นเชิง

อย่าสร้างประเภทใหม่หากคุณสามารถช่วยได้ พวกเขาสามารถทำให้เกิดความสับสนความซับซ้อนและนำไปสู่รหัสเพิ่มเติมเพื่อรักษา พวกเขาอาจทำให้รหัสของคุณต้องขยาย การออกแบบลำดับชั้นข้อยกเว้นนั้นจำเป็นต้องใช้จำนวนมากและการทดสอบ มันไม่ใช่ความคิด เป็นการดีที่สุดที่จะใช้ลำดับชั้นข้อยกเว้นทางภาษาในตัว

เนื้อหาของข้อความแสดงข้อยกเว้นขึ้นอยู่กับผู้รับข้อความดังนั้นคุณต้องใส่ตัวเองในรองเท้าของบุคคลนั้น

วิศวกรฝ่ายสนับสนุนจะต้องสามารถระบุแหล่งที่มาของข้อผิดพลาดได้โดยเร็วที่สุด รวมสตริงที่สื่อความหมายสั้น ๆ รวมถึงข้อมูลใด ๆ ที่สามารถช่วยแก้ไขปัญหาได้ รวมการติดตามสแต็กเสมอ - หากทำได้ - นี่จะเป็นแหล่งข้อมูลที่แท้จริงเท่านั้น

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

นอกจากนี้ - อย่าโยน "HALT ERROR!" ไอคอน. มันเป็นข้อผิดพลาด - ไม่ใช่จุดสิ้นสุดของโลก

ดังนั้นโดยสรุป: คิดถึงนักแสดงและใช้เคสสำหรับระบบของคุณ ใส่ตัวเองในรองเท้าของผู้ใช้เหล่านั้น เป็นประโยชน์ เป็นคนดี คิดเกี่ยวกับสิ่งนี้ล่วงหน้าในการออกแบบระบบของคุณ จากมุมมองของผู้ใช้ของคุณ - กรณีข้อยกเว้นเหล่านี้และวิธีที่ระบบจัดการกับพวกเขานั้นมีความสำคัญเท่ากับกรณีปกติในระบบของคุณ