แนวทางปฏิบัติที่ดีที่สุดในการสร้างรูปแบบรหัสข้อผิดพลาดสำหรับโครงการระดับองค์กรใน C # [ปิด]


43

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

แนวทางปฏิบัติและคำแนะนำที่ดีที่สุดในการทำสิ่งนี้คืออะไร?
ความช่วยเหลือใด ๆ ในการทำเช่นนี้จะเป็นประโยชน์


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

ขึ้นอยู่กับโครงสร้างธุรกิจของคุณ ใน C # เราให้โอกาสผู้ใช้ในการส่ง StackTrace ให้กับเราทางไปรษณีย์หรือคัดลอก / วางจากรายละเอียดข้อความแสดงข้อผิดพลาด (เราไม่มีข้อกำหนดด้านความปลอดภัยที่เข้มงวด)
Falcon

คำตอบ:


69

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

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

นี่คือวิธีที่ฉันจะจัดระเบียบ (โปรดทราบว่าจุด 2-6 เป็นผู้ไม่เชื่อเรื่องภาษา):

  1. ใช้ประเภทข้อยกเว้นที่กำหนดเองพร้อมกับErrorCodeคุณสมบัติเพิ่มเติม catch ในลูปหลักจะรายงานฟิลด์นี้ตามปกติ (ล็อกไฟล์ / ข้อผิดพลาดป๊อปอัพ / ตอบกลับข้อผิดพลาด) ใช้ประเภทข้อยกเว้นเดียวกันในรหัสของคุณทั้งหมด
  2. อย่าเริ่มต้นที่ 1 และไม่ใช้ศูนย์นำหน้า ให้รหัสข้อผิดพลาดทั้งหมดมีความยาวเท่ากันดังนั้นรหัสข้อผิดพลาดที่ผิดพลาดนั้นสามารถมองเห็นได้ง่าย เริ่มต้นที่ 1,000 มักจะดีพอ อาจเพิ่ม 'E' นำหน้าเพื่อให้ผู้ใช้สามารถระบุตัวตนได้อย่างชัดเจน (มีประโยชน์โดยเฉพาะเมื่อฝ่ายสนับสนุนมีการแนะนำผู้ใช้ถึงวิธีการสังเกตรหัสข้อผิดพลาด)
  3. เก็บรายชื่อของรหัสข้อผิดพลาดทั้งหมด แต่ไม่ทำเช่นนี้ในรหัสของคุณ เก็บรายการสั้น ๆ ไว้ในหน้า wiki สำหรับนักพัฒนาซึ่งพวกเขาสามารถแก้ไขได้อย่างง่ายดายเมื่อพวกเขาต้องการรหัสใหม่ ฝ่ายช่วยเหลือควรมีรายการแยกต่างหากในวิกิของตนเอง
  4. อย่าพยายามบังคับใช้โครงสร้างในรหัสข้อผิดพลาด จะมีข้อผิดพลาดที่ยากต่อการจำแนกและคุณไม่ต้องการพูดคุยนานหลายชั่วโมงว่าข้อผิดพลาดควรอยู่ในกลุ่ม 45xx หรือในกลุ่ม 54xx มีการปฏิบัติ
  5. กำหนดรหัสแยกแต่ละครั้งในรหัสของคุณ แม้ว่าคุณคิดว่ามันเป็นสาเหตุเดียวกันแผนกช่วยเหลืออาจต้องทำสิ่งต่าง ๆ ในกรณีที่แตกต่างกัน ง่ายกว่าสำหรับพวกเขาที่จะมี "E1234: ดู E1235" ในวิกิของพวกเขามากกว่าที่จะให้ผู้ใช้สารภาพสิ่งที่เขาทำผิด
  6. แยกรหัสข้อผิดพลาดถ้าฝ่ายช่วยเหลือขอให้ if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");บรรทัดที่เรียบง่ายในรหัสของคุณอาจช่วยครึ่งชั่วโมงสำหรับแผนกให้ความช่วยเหลือ

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


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

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

ลวดลายของฉันคล้ายกันมาก แต่แทนที่จะเป็น "E" ฉันได้เพิ่มส่วนหนึ่งของแอพ เอกสารกรอบของเรามีเช่นDoc1234ในขณะที่หลัก App IrS1234สามารถมี ดังนั้นฝ่ายช่วยเหลือเพื่อนร่วมงานของฉันจึงค่อนข้างรวดเร็วด้วยการช่วยเหลือผู้ใช้ของฉัน
Matthias Burger

6

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

ง่าย ๆ ในทางทฤษฎี .. ในทางปฏิบัติข้อผิดพลาดสามารถเกิดขึ้นได้ทุกที่และการรายงานพวกเขาสามารถเปลี่ยนรหัสที่ดีให้กลายเป็นสัตว์ประหลาดของการบันทึกการขว้างและการจัดการยกเว้นและการส่งคืนค่า

ฉันจะแนะนำวิธีการสองขั้นตอนแล้ว แรกคือการเข้าสู่ระบบเข้าสู่ระบบจำนวนมากและจำนวนมาก

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

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


3

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


1
ฉันอยากจะขอบคุณคนที่ downvoted คำตอบนี้ 1-0 ไปอย่างน้อยให้เหตุผล ...
สเตฟาน Billiet

1
ไม่ใช่ฉัน downvoting (ไม่ใช่ว่ามันเป็นเรื่องสำคัญ, เอาชนะมันได้) แต่ฉันคิดว่ามีการสนับสนุนที่มีอยู่สำหรับค่าตอบแทนในภาษาด้วย
gbjbaanb

2
มันสำคัญสำหรับฉัน หากฉันผิดฉันต้องการทราบเพื่อที่ฉันจะได้เรียนรู้ :-p คุณหมายถึงอะไรการสนับสนุนที่มีอยู่สำหรับค่าตอบแทนคืน? คุณไม่ต้องเขียนระบบประปาเพื่อแยกความแตกต่างของค่าส่งคืนปกติจากรหัสข้อผิดพลาดหรือไม่? การแปลข้อยกเว้นเป็นรหัสข้อผิดพลาดที่ขอบเขตของระบบเป็นสิ่งหนึ่ง แต่การเล่นกลพวกเขาภายในระบบของคุณเป็นสิ่งที่แนะนำโดยทั่วไป ฉันเชื่อว่า The Pragmatic Programmer กล่าวถึงของประเภทนี้
Stefan Billiet

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

6
ฉันไม่ได้ลงคะแนนคุณ (เอาง่ายๆไม่งั้นทุกคนจะต้องทำซ้ำ :) หากคุณเคยทำงานหรือโทรหาที่แผนกบริการคุณจะสื่อสารได้ง่ายกว่าการส่งข้อความผิดพลาด ข้อความแสดงข้อผิดพลาดรับประกันว่าจะเปลี่ยนแปลงเมื่อมีการสื่อสารด้วยวาจา
Codism
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.