Cách thực hành tốt nhất để tạo mẫu mã lỗi cho dự án doanh nghiệp trong C # [đã đóng]

Tôi đang làm việc trong một dự án doanh nghiệp sẽ được triển khai ở nhiều SMB và Doanh nghiệp.
Sự hỗ trợ cho dự án này sẽ gặp khó khăn và vì vậy tôi muốn tạo một mẫu mã cho các lỗi ( Giống như Mã trạng thái HTTP ). Điều này sẽ cho phép người trợ giúp tham khảo tài liệu và khắc phục sự cố càng sớm càng tốt.

Các thực tiễn và khuyến nghị tốt nhất để làm điều này là gì?
Bất kỳ trợ giúp để làm điều này sẽ hữu ích.

Có sự khác biệt giữa mã lỗi và giá trị trả về lỗi. Mã lỗi dành cho người dùng và bàn trợ giúp. Giá trị trả về lỗi là một kỹ thuật mã hóa để chỉ ra rằng mã của bạn đã gặp lỗi.

Người ta có thể thực hiện mã lỗi bằng cách sử dụng các giá trị trả về lỗi, nhưng tôi sẽ khuyên điều đó. Ngoại lệ là cách hiện đại để báo cáo lỗi và không có lý do nào khiến chúng không mang mã lỗi bên trong chúng.

Đây là cách tôi sẽ tổ chức nó (Lưu ý rằng các điểm 2-6 là bất khả tri ngôn ngữ):

1. Sử dụng một loại ngoại lệ tùy chỉnh với một thuộc tính bổ sung ErrorCode. Việc bắt trong vòng lặp chính sẽ báo cáo trường này theo cách thông thường (tệp nhật ký / lỗi bật lên / trả lời lỗi). Sử dụng cùng một loại ngoại lệ trong tất cả các mã của bạn.
2. Đừng bắt đầu từ 1 và đừng sử dụng các số 0 đứng đầu. Giữ tất cả các mã lỗi có cùng độ dài, vì vậy một mã lỗi sai rất dễ phát hiện. Bắt đầu từ 1000 thường là đủ tốt. Có thể thêm một 'E' hàng đầu để làm cho chúng có thể nhận dạng rõ ràng cho người dùng (đặc biệt hữu ích khi bàn hỗ trợ phải hướng dẫn người dùng cách phát hiện mã lỗi).
3. Giữ một danh sách tất cả các mã lỗi, nhưng đừng làm điều này trong mã của bạn . Giữ một danh sách ngắn trên trang wiki dành cho nhà phát triển, họ có thể dễ dàng chỉnh sửa khi họ cần mã mới. Bàn trợ giúp nên có một danh sách riêng trên wiki của riêng họ.
4. Đừng cố thực thi một cấu trúc trên các mã lỗi. Sẽ luôn có những lỗi khó phân loại và bạn không muốn thảo luận hàng giờ về việc một lỗi nên thuộc nhóm 45xx hay trong nhóm 54xx. Hãy thực dụng .
5. Chỉ định mỗi lần ném trong mã của bạn một mã riêng. Mặc dù bạn nghĩ đó là cùng một nguyên nhân, bàn trợ giúp có thể cần phải làm những việc khác nhau trong các trường hợp khác nhau. Việc họ có "E1234: Xem E1235" trong wiki của họ dễ dàng hơn so với việc khiến người dùng thú nhận những gì anh ta đã làm sai.
6. Tách mã lỗi nếu bàn trợ giúp yêu cầu. Một if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");dòng đơn giản trong mã của bạn có thể tiết kiệm nửa giờ cho bàn trợ giúp.

Và đừng bao giờ quên rằng mục đích của các mã lỗi là làm cho cuộc sống dễ dàng hơn cho bàn trợ giúp .

Trước tiên, bạn phải cách ly các khu vực có thể xảy ra lỗi và người dùng có thể nhìn thấy. Sau đó, bạn có thể ghi lại chúng. Nó đơn giản mà.

Vâng, đơn giản về lý thuyết .. trong thực tế, lỗi có thể xảy ra ở khắp nơi, và báo cáo chúng có thể biến mã đẹp thành một con quái vật ghi nhật ký, ném ngoại lệ và xử lý, và chuyển các giá trị trả về.

Tôi muốn giới thiệu một cách tiếp cận 2 bước sau đó. Đầu tiên là đăng nhập, đăng nhập rất nhiều.

Thứ hai là xác định các thành phần chính và giao diện của chúng và để xác định trường hợp lỗi chính nào mà các thành phần này có thể tự tìm thấy. Sau đó, bạn có thể đăng nhập theo cách dễ thấy hơn khi một trong những lỗi này (cách bạn xử lý lỗi bên trong tùy thuộc vào bạn - ngoại lệ hoặc mã lỗi không tạo ra sự khác biệt ở đây). Một người dùng thường sẽ nhìn thấy lỗi và đi đến nhật ký để biết thông tin chi tiết hơn.

Cách tiếp cận tương tự được sử dụng cho các máy chủ web và ví dụ mã lỗi http của bạn. Nếu người dùng nhìn thấy 404 và báo cáo nó để hỗ trợ, họ sẽ xem nhật ký để biết chi tiết về những gì đang diễn ra, trang nào đã được truy cập, khi nào và sẽ lượm lặt bất kỳ thông tin nào khác mà họ có thể biết , trong DB, mạng hoặc ứng dụng.

Tôi sẽ đi cho các trường hợp ngoại lệ tùy chỉnh với tên mô tả và thông điệp rõ ràng và ném chúng. Việc sử dụng cơ sở hạ tầng ngoại lệ hiện tại của ngôn ngữ dễ dàng hơn nhiều so với xây dựng hỗ trợ cho việc truyền mã lỗi xung quanh và giải thích chúng.