นักพัฒนามีปัญหาอะไรกับข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์? [ปิด]

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

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

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

ตัวเลือกอื่นเช่น SQL Server (และ mySQL) คือstring or binary data would be truncatedข้อความแสดงข้อผิดพลาดที่น่ารักและรายการเทียบเท่า บ่อยครั้งที่การอ่านคำสั่ง SQL อย่างง่าย ๆ ที่สร้างขึ้นและตารางแสดงว่าคอลัมน์ใดเป็นผู้ร้าย นี่ไม่ใช่กรณีเสมอไปและหากเอ็นจิ้นฐานข้อมูลหยิบขึ้นมาบนข้อผิดพลาดทำไมมันไม่สามารถช่วยเราได้ในเวลานั้นและเพียงแค่บอกเราว่ามันเป็นคอลัมน์ใด ในตัวอย่างนี้คุณสามารถยืนยันว่าอาจมีการแสดงที่มีประสิทธิภาพในการตรวจสอบและสิ่งนี้อาจเป็นอุปสรรคต่อผู้เขียน ใช่ฉันจะซื้อมัน เมื่อกลไกจัดการฐานข้อมูลรู้ว่ามีข้อผิดพลาดจะทำการเปรียบเทียบอย่างรวดเร็วหลังจากความจริงระหว่างค่าที่จะถูกจัดเก็บเทียบกับความยาวคอลัมน์ จากนั้นแสดงให้ผู้ใช้เห็น

Adaptors Table ที่น่ากลัวของ ASP.NET ก็มีความผิดเช่นกัน สามารถดำเนินการค้นหาและสามารถได้รับข้อความแสดงข้อผิดพลาดที่บอกว่าข้อ จำกัด บางแห่งกำลังถูกละเมิด ขอบคุณสำหรับสิ่งนั้น เวลาเปรียบเทียบแบบจำลองข้อมูลของฉันกับฐานข้อมูลเนื่องจากผู้พัฒนาขี้เกียจเกินกว่าที่จะให้หมายเลขแถวหรือข้อมูลตัวอย่าง (สำหรับบันทึกฉันไม่เคยใช้วิธีการเข้าถึงข้อมูลนี้โดยทางเลือกมันเป็นเพียงโครงการที่ฉันได้รับมา!)

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

อาจมีการยืนยันว่าข้อความข้อยกเว้นที่ซับซ้อนไม่ควรแสดงต่อผู้ใช้ ในขณะที่ฉันไม่เห็นด้วยกับสิ่งนั้นมันเป็นข้อโต้แย้งที่สามารถทำให้สบายใจได้โดยการใช้คำฟุ่มเฟือยในระดับที่แตกต่างกันขึ้นอยู่กับงานสร้างของคุณ ถึงกระนั้นก็ตามผู้ใช้ ASP.NET และ SQL Server ไม่ใช่ผู้ใช้ทั่วไปของคุณและต้องการบางสิ่งที่เต็มไปด้วยข้อมูล verbosity และ yummy เพราะพวกเขาสามารถติดตามปัญหาได้เร็วขึ้น

ทำไมนักพัฒนาถึงคิดว่าไม่เป็นไรในยุคนี้เพื่อให้ข้อมูลขั้นต่ำเปล่าเมื่อเกิดข้อผิดพลาด?

มันเป็น 2,011 คนมาใน

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

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

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

นักพัฒนาไม่ใช่คนที่เหมาะสมในการเขียนข้อความผิดพลาด

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

มุมมองการกุศล:

• นักพัฒนาทำงานอย่างใกล้ชิดกับรหัสและพยายามเข้าใจคนที่ไม่เข้าใจการทำงานกับมัน ผลก็คือพวกเขาคิดว่าข้อความแสดงข้อผิดพลาดนั้นใช้ได้ แต่พวกเขาไม่มีกรอบอ้างอิงที่ดีพอที่จะตัดสินพวกเขา

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

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

มุมมองที่ไม่เป็นอันตราย:

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

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

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

ฉันยอมรับว่าข้อความแสดงข้อผิดพลาดควรมีความเฉพาะเจาะจงที่สุดเท่าที่จะทำได้

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

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

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

โปรแกรมเมอร์ของเราได้รับการฝึกฝนให้ดูแลการป้องกันตนเองของขั้นตอนที่วางแผนไว้นี้ ดังนั้นเราจึงรวมการตรวจสุขภาพจิตเพื่อตรวจสอบสมมติฐานของเราเป็นประจำ เมื่อสติเหล่านี้ตรวจสอบล้มเหลวเราเพิ่งรู้ว่าแผนล้มเหลวอย่างใด ...

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

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

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

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

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

ดูเหมือนว่าสำหรับฉันแม้ว่าจะไม่ได้นำเสนอให้กับผู้ใช้ แต่ก็ปลอดภัยสำหรับเราหากทีม dev จะเพิ่มบันทึกลงในเอกสารดัชนีข้อผิดพลาด doc หรือฐานข้อมูลเมื่อใดก็ตามที่พวกเขาเพิ่มใหม่มันจะทำให้มัน ไกลเร็วกว่าที่เราจะหาสาเหตุของปัญหาลูกค้าและประหยัดเวลาเช่นกัน ...

ปัญหาที่คุณเห็นนั่นเป็นหนึ่งในผลข้างเคียงของการห่อหุ้มที่เหมาะสมและการซ่อนข้อมูล

ระบบสมัยใหม่มีความซับซ้อนอย่างยิ่ง มีโอกาสน้อยที่ผู้พัฒนาโดยเฉลี่ยจะถือเป็นแบบจำลองทางจิตของระบบทั้งหมดจาก UI ไปยังไบนารีดิบในขณะที่เขากำลังเข้ารหัสงานเฉพาะใด ๆ

ดังนั้นในขณะที่นักพัฒนากำลังนั่งและเขียนโค้ดบิตที่กู้คืนไฟล์ฐานข้อมูลแบบจำลองทางจิตของเขาเต็มไปด้วยบิตที่ล้อมรอบการกระทำในการกู้คืนไฟล์ฐานข้อมูล เขาต้องการที่จะ (และฉันคาดเดาฉันไม่ได้เขียนรหัสนี้) อ่านไฟล์ตรวจสอบคุณสมบัติอ่านรุ่นสำรองข้อมูลที่มีอยู่ให้เลือกกลยุทธ์การผสาน / เขียนทับ ฯลฯ ค่อนข้างมีโอกาสถ้ามีแม้ผ่าน พิจารณาถึง UI ในสตริงข้อผิดพลาดที่เขาเขียนในตัวจัดการข้อยกเว้น สิ่งที่ต้องการ:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

ในตัวอย่างนี้ข้อมูลที่เป็นประโยชน์ที่คุณถามเกี่ยวกับในแง่ของกระบวนการที่อาจใช้ไฟล์หรือแม้กระทั่งเธรดอื่น ๆ ในฐานข้อมูลอยู่นอกขอบเขตโดยสมบูรณ์ (โดยทางโปรแกรม) อาจมีหลายร้อยชั้นเรียนที่จัดการกับไฟล์ DB; การนำเข้าข้อมูลให้กับผู้เรียนเกี่ยวกับกระบวนการอื่น ๆ ทุกการใช้ไฟล์หรือฟังก์ชั่นในการเข้าถึงระบบไฟล์และดูที่กระบวนการอื่น ๆ ที่ทำงาน (สมมติว่ากระบวนการเหล่านี้จะได้บนเครื่องนี้) จะส่งผลให้ในสิ่งที่เป็นที่รู้จักกันเป็นนามธรรมรั่ว ; มีต้นทุนโดยตรงในการผลิต

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

สิ่งที่ฉันชอบคือ (ย้อนกลับไปในช่วงปลายยุค 70) คอมไพเลอร์ Univac Fortran IV เมื่ออ่านตัวเลขที่ไม่ใช่ตัวเลขประกาศอย่างซื่อสัตย์

พยายามตีความข้อมูลที่ไม่มีความหมาย

ฉันเชื่อว่าส่วนใหญ่ของข้อความผิดพลาดเป็นจริงโปรแกรมเมอร์ (ตนเอง) ที่มุ่งเน้นการแก้ไขข้อบกพร่องรหัส / คำสั่ง printf glorified

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

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

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

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

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

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

การทำมันมักจะต้องมีเพศสัมพันธ์ที่ไม่จำเป็นหากกลไกการรายงานข้อผิดพลาดไม่ได้เป็นพลเมืองชั้นหนึ่งในช่วงการออกแบบ ฉันเดาว่าคนส่วนใหญ่เพิ่งพบว่างานมากเกินไปที่จะทำในสิ่งที่ดูไม่น่าประทับใจ (ใครจะพูดว่า "เห็นโปรแกรมของฉันล้มเหลวและข้อความแสดงข้อผิดพลาดมีประโยชน์!")