ควรแสดงข้อมูลเกี่ยวกับข้อผิดพลาดแก่ผู้ใช้มากน้อยเพียงใด

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

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

ตัวอย่างเช่นภาษาที่รองรับข้อยกเว้น (.net, java) มีประเภทข้อยกเว้นที่จะแบ่งปันโดยที่ข้อยกเว้นเกิดขึ้นและข้อความที่ค่อนข้างชัดเจนเพื่อให้สอดคล้องกับข้อยกเว้น สิ่งนี้ควรถูกซ่อนจากผู้ใช้ด้วยหรือไม่ หรือเราควรแสดงสิ่งนี้ต่อไป? หรือเราควรแสดงข้อความทั่วไป? หรือเราควรแสดงหนึ่งในจำนวนข้อความตามข้อยกเว้นพื้นฐานคืออะไร

สิ่งที่จะแสดงต่อผู้ใช้ สิ่งนี้ควรถูกซ่อนจากผู้ใช้ด้วยหรือไม่

คุณแสดงให้ผู้ใช้เห็นสิ่งที่สามารถดำเนินการได้สำหรับพวกเขา

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

หรือเราควรแสดงสิ่งนี้ต่อไป? หรือเราควรแสดงข้อความทั่วไป?

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

เราควรแสดงข้อความหนึ่งในจำนวนหนึ่งตามข้อยกเว้นที่สำคัญคืออะไร

กลยุทธ์ที่ดีที่สุดคือทำสิ่งต่อไปนี้:

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

ตัวอย่าง

1. มันแสดงให้เห็นว่า "นี่คือสิ่งที่เกิดขึ้น" (ข้อผิดพลาดที่ไม่คาดคิด)
2. บอกผู้ใช้ว่าต้องทำอะไร (เปิด Mail อีกครั้งรวมถึงทางลัดในการทำเช่นนี้)
3. นอกจากนี้ยังมี "ดูรายละเอียด" หากมีคนอยากรู้อยากเห็นเพื่อดูข้อผิดพลาดทางเทคนิคแบบเต็ม
4. ให้การแจ้งเตือนรายงานข้อผิดพลาดจะถูกยื่น (ดูด้านล่าง)

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

ขึ้นอยู่กับว่าผู้ใช้คือใครและทำอะไรกับข้อมูล

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

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

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

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

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

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

นี่เป็นธีมทั่วไป:

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

ฉันคิดว่าคำตอบคือคุณทำทั้งสองอย่าง!

คำสั่งซื้อนั้นสำคัญและฉันขอแนะนำให้คุณ:

• เกิดอะไรขึ้น.
• สิ่งที่ต้องทำตอนนี้
• รายละเอียดทางเทคนิค

รายละเอียดทางเทคนิคเป็นส่วนที่มีข้อมูลสำหรับคำสั่งซื้อขั้นสูงหรือสำหรับผู้ใช้ปกติเมื่อรายงานปัญหา

สิ่งที่คุณต้องการแสดงนั้นขึ้นอยู่กับว่าคุณละอายใจเพียงใด

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

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

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

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

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

และบ่อยครั้งในแง่ของการจัดการข้อยกเว้นฉันคิดว่าคุณมักจะมีข้อมูลพื้นฐานเพียงพอในสิ่งที่เกิดขึ้นที่catchไซต์แม้ว่าคุณจะต้องการซ่อนรายละเอียดทางเทคนิคเพิ่มเติมของข้อยกเว้นเช่น:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

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

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