ข้อความเหล่านี้มีไว้สำหรับนักพัฒนาอื่น ๆ
นักพัฒนาคาดว่าจะสามารถอ่านข้อความเหล่านี้ได้เพื่อช่วยในการดีบักแอปพลิเคชัน สิ่งนี้มีสองรูปแบบ:
การดีบักที่ใช้งานอยู่ คุณกำลังเรียกใช้ดีบักเกอร์ในขณะที่เขียนรหัสและพยายามคิดว่าจะเกิดอะไรขึ้น ในบริบทนี้ข้อยกเว้นที่มีประโยชน์จะแนะนำคุณโดยทำให้ง่ายต่อการเข้าใจว่าเกิดอะไรขึ้นหรือในที่สุดก็แนะนำวิธีแก้ปัญหา (แม้ว่านี่จะเป็นทางเลือก)
การดีบักแบบพาสซีฟ รหัสทำงานในการผลิตและล้มเหลว ข้อยกเว้นถูกบันทึกไว้ แต่คุณจะได้รับข้อความและการติดตามสแต็กเท่านั้น ในบริบทนี้ข้อความแสดงข้อยกเว้นที่มีประโยชน์จะช่วยให้คุณทำการแปลบั๊กได้อย่างรวดเร็ว
เนื่องจากข้อความเหล่านั้นมักถูกบันทึกไว้ก็หมายความว่าคุณไม่ควรรวมข้อมูลที่ละเอียดอ่อนไว้ที่นั่น (เช่นคีย์ส่วนตัวหรือรหัสผ่านแม้ว่าจะเป็นประโยชน์ในการดีบักแอป)
ตัวอย่างเช่นIOSecurityExceptionชนิดของข้อผิดพลาดเกิดขึ้นเมื่อเขียนไฟล์ไม่ชัดเจนมากเกี่ยวกับปัญหา: เป็นเพราะเราไม่มีสิทธิ์ในการเข้าถึงไฟล์หรือไม่ หรือบางทีเราสามารถอ่านได้ แต่ไม่ใช่เขียน? หรืออาจไม่มีไฟล์อยู่และเราไม่มีสิทธิ์ในการสร้างไฟล์ที่นั่น หรืออาจถูกล็อค (หวังว่าประเภทของข้อยกเว้นจะแตกต่างกันในกรณีนี้ แต่ในทางปฏิบัติบางครั้งประเภทอาจเป็นความลับ) หรือบางทีความปลอดภัยในการเข้าถึงรหัสทำให้เราไม่สามารถทำงาน I / O ได้?
แทน:
IOSecurityException: พบไฟล์ แต่สิทธิ์ในการอ่านเนื้อหาถูกปฏิเสธ
ชัดเจนมากขึ้น ที่นี่เรารู้ทันทีว่าการอนุญาตในไดเรกทอรีถูกตั้งค่าอย่างถูกต้อง (ไม่เช่นนั้นเราจะไม่สามารถรู้ได้ว่ามีไฟล์อยู่) แต่การอนุญาตที่ระดับไฟล์นั้นเป็นปัญหา
ซึ่งหมายความว่าหากคุณไม่สามารถให้ข้อมูลเพิ่มเติมใด ๆ ที่ไม่ได้อยู่ในประเภทของข้อยกเว้นคุณสามารถทำให้ข้อความว่างเปล่า DivisionByZeroExceptionเป็นตัวอย่างที่ดีที่มีข้อความซ้ำซ้อน ในทางกลับกันความจริงที่ว่าภาษาส่วนใหญ่อนุญาตให้คุณโยนข้อยกเว้นโดยไม่ระบุข้อความของมันจะทำด้วยเหตุผลที่แตกต่าง: เนื่องจากข้อความเริ่มต้นมีอยู่แล้วหรือเพราะมันจะถูกสร้างขึ้นในภายหลังถ้าจำเป็น (และรุ่นนี้ ข้อความถูกล้อมรอบอยู่ในประเภทยกเว้นซึ่งทำให้รู้สึกที่สมบูรณ์แบบการพูด"OOPly" )
โปรดทราบว่าสำหรับเหตุผลทางเทคนิค (มักจะมีประสิทธิภาพ) ข้อความบางข้อความอาจมีความลับมากกว่าที่ควรเป็น . NET's NullReferenceException:
การอ้างอิงวัตถุไม่ได้ถูกตั้งค่าเป็นอินสแตนซ์ของวัตถุ
เป็นตัวอย่างที่ดีของข้อความที่ไม่เป็นประโยชน์ ข้อความที่เป็นประโยชน์จะเป็น:
วัตถุการอ้างอิงที่ไม่ได้กำหนดให้ตัวอย่างของวัตถุเมื่อเรียกproductproduct.Price
ข้อความเหล่านั้นไม่ได้มีไว้สำหรับผู้ใช้ปลายทาง!
ผู้ใช้ปลายทางไม่คาดว่าจะเห็นข้อความข้อยกเว้น ไม่เคย แม้ว่านักพัฒนาซอฟต์แวร์บางรายจะแสดงข้อความเหล่านั้นแก่ผู้ใช้ แต่สิ่งนี้นำไปสู่ประสบการณ์การใช้งานที่ไม่ดี ข้อความเช่น:
การอ้างอิงวัตถุไม่ได้ถูกตั้งค่าเป็นอินสแตนซ์ของวัตถุ
ไม่มีความหมายอะไรกับผู้ใช้อย่างแน่นอนและควรหลีกเลี่ยงค่าใช้จ่ายทั้งหมด
สถานการณ์กรณีที่เลวร้ายที่สุดคือการลอง / จับทั่วโลกซึ่งจะส่งข้อยกเว้นให้ผู้ใช้และออกจากแอป แอปพลิเคชันที่ใส่ใจผู้ใช้:
จัดการข้อยกเว้นในตอนแรก คนส่วนใหญ่สามารถจัดการได้โดยไม่รบกวนผู้ใช้ เครือข่ายขัดข้อง ทำไมไม่รอสักครู่แล้วลองใหม่อีกครั้ง
ป้องกันผู้ใช้จากการนำแอปพลิเคชันไปเป็นกรณีพิเศษ หากคุณขอให้ผู้ใช้ป้อนตัวเลขสองตัวแล้วหารหมายเลขแรกด้วยตัวเลขที่สองทำไมคุณถึงปล่อยให้ผู้ใช้ป้อนค่าศูนย์ในกรณีที่สองเพื่อตำหนิเขาในไม่กี่วินาทีต่อมา สิ่งที่เกี่ยวกับการเน้นกล่องข้อความเป็นสีแดง (ด้วยเคล็ดลับเครื่องมือที่มีประโยชน์บอกว่าหมายเลขควรจะแตกต่างจากศูนย์) และปิดการใช้งานปุ่มตรวจสอบจนกว่าสนามยังคงเป็นสีแดง?
เชิญผู้ใช้ให้ดำเนินการในรูปแบบที่ไม่ใช่ข้อผิดพลาด ไม่มีสิทธิ์เพียงพอในการเข้าถึงไฟล์หรือไม่ ทำไมไม่ขอให้ผู้ใช้ให้สิทธิ์การดูแลระบบหรือเลือกไฟล์อื่น
หากไม่มีสิ่งใดทำงานแสดงข้อผิดพลาดที่เป็นประโยชน์และเป็นมิตรซึ่งเขียนขึ้นโดยเฉพาะเพื่อลดความขัดข้องของผู้ใช้ช่วยให้ผู้ใช้เข้าใจสิ่งที่ผิดพลาดและแก้ไขปัญหาได้ในที่สุดและช่วยให้เขาป้องกันข้อผิดพลาดในอนาคต
ในคำถามของคุณคุณแนะนำให้มีข้อความสองข้อยกเว้น: ข้อความทางเทคนิคสำหรับนักพัฒนาและข้อความสำหรับผู้ใช้ แม้ว่านี่จะเป็นข้อเสนอแนะที่ถูกต้องในบางกรณี แต่ข้อยกเว้นส่วนใหญ่จะถูกสร้างขึ้นในระดับที่ไม่สามารถสร้างข้อความที่มีความหมายสำหรับผู้ใช้ ลองDivisionByZeroExceptionจินตนาการว่าเราไม่สามารถป้องกันข้อยกเว้นจากสิ่งที่เกิดขึ้นและไม่สามารถจัดการได้ด้วยตนเอง เมื่อการแบ่งเกิดขึ้นกรอบงาน (เนื่องจากเป็นกรอบงานและไม่ใช่รหัสธุรกิจที่ส่งข้อยกเว้น) รู้ว่าข้อความใดจะมีประโยชน์สำหรับผู้ใช้หรือไม่ ไม่ได้อย่างแน่นอน:
การหารด้วยศูนย์เกิดขึ้น [ตกลง]
แต่เราสามารถปล่อยให้มันเป็นข้อยกเว้นแล้วจับมันในระดับที่สูงขึ้นซึ่งเรารู้บริบททางธุรกิจและสามารถดำเนินการตามนั้นเพื่อช่วยผู้ใช้ปลายทางได้อย่างแท้จริงดังนั้นจึงแสดงดังนี้:
ฟิลด์ D13 ไม่สามารถมีค่าเหมือนกับค่าในฟิลด์ E6 เนื่องจากการลบค่าเหล่านั้นถูกใช้เป็นตัวหาร [ตกลง]
หรืออาจจะ:
ค่าที่รายงานโดยบริการ ATP ไม่สอดคล้องกับข้อมูลท้องถิ่น สิ่งนี้อาจเกิดจากข้อมูลในเครื่องไม่ซิงค์กัน คุณต้องการซิงโครไนซ์ข้อมูลการจัดส่งและลองอีกครั้งหรือไม่ [ใช่ไม่ใช่]
ข้อความเหล่านั้นไม่ได้มีไว้สำหรับการแยกวิเคราะห์
ข้อความคาดว่าจะไม่ถูกแยกวิเคราะห์หรือใช้โดยทางโปรแกรมเช่นกัน หากคุณคิดว่าผู้โทรสามารถขอข้อมูลเพิ่มเติมได้ให้รวมไว้ในข้อความข้อยกเว้นแบบเคียงข้างพร้อมกับข้อความ นี่เป็นสิ่งสำคัญเนื่องจากข้อความอาจเปลี่ยนแปลงได้โดยไม่ต้องแจ้งให้ทราบล่วงหน้า Type เป็นส่วนหนึ่งของอินเตอร์เฟส แต่ข้อความไม่ได้: ไม่ต้องพึ่งพามันสำหรับการจัดการข้อยกเว้น
ลองนึกภาพข้อความข้อยกเว้น:
การเชื่อมต่อกับแคชตัดการหมดเวลาหลังจากรอ 500 ms เพิ่มการหมดเวลาหรือตรวจสอบการตรวจสอบประสิทธิภาพเพื่อระบุการลดลงของประสิทธิภาพเซิร์ฟเวอร์ เวลารอเฉลี่ยสำหรับแคชเซิร์ฟเวอร์คือ 6 ms สำหรับเดือนที่แล้ว 4 ms สำหรับสัปดาห์ที่แล้วและ 377 มิลลิวินาที สำหรับชั่วโมงสุดท้าย
คุณต้องการแยกค่า“ 500”,“ 6”,“ 4” และ“ 377” คิดเล็กน้อยเกี่ยวกับวิธีที่คุณจะใช้ในการแยกวิเคราะห์แล้วอ่านต่อ
คุณมีความคิด? ยิ่งใหญ่
ตอนนี้ผู้พัฒนาดั้งเดิมค้นพบตัวพิมพ์ผิด:
Connecting to the caching sever timed out after waiting [...]
ควรจะเป็น:
↓
Connecting to the caching server timed out after waiting [...]
ยิ่งกว่านั้นนักพัฒนาซอฟต์แวร์เห็นว่าเดือน / สัปดาห์ / หนึ่งชั่วโมงไม่เกี่ยวข้องกันเป็นพิเศษดังนั้นเขาจึงทำการเปลี่ยนแปลงเพิ่มเติม:
เวลารอเฉลี่ยสำหรับแคชเซิร์ฟเวอร์คือ 6 ms สำหรับเดือนที่แล้ว 5 ms ในช่วง 24 ชั่วโมงที่ผ่านมาและ 377 มิลลิวินาที สำหรับชั่วโมงสุดท้าย
เกิดอะไรขึ้นกับการแยกวิเคราะห์ของคุณ
แทนที่จะแยกวิเคราะห์คุณสามารถใช้คุณสมบัติข้อยกเว้น (ซึ่งสามารถมีสิ่งที่ต้องการทันทีที่ข้อมูลสามารถต่อเนื่องได้):
{
message: "Connecting to the caching [...]",
properties: {
"timeout": 500,
"statistics": [
{ "timespan": 1, "unit": "month", "average-timeout": 6 },
{ "timespan": 7, "unit": "day", "average-timeout": 4 },
{ "timespan": 1, "unit": "hour", "average-timeout": 377 },
]
}
}
การใช้ข้อมูลนี้ง่ายแค่ไหน?
บางครั้ง (เช่นภายใน. NET) ข้อความสามารถแปลเป็นภาษาของผู้ใช้ได้ (IMHO การแปลข้อความเหล่านั้นผิดอย่างยิ่งเนื่องจากผู้พัฒนาคาดว่าจะสามารถอ่านภาษาอังกฤษได้) การแยกข้อความดังกล่าวใกล้จะเป็นไปไม่ได้