Khi nào bắt đầu viết Xử lý ngoại lệ, Ghi nhật ký

Khi nào bạn bắt đầu viết Mã xử lý ngoại lệ? Khi nào bạn bắt đầu viết Báo cáo đăng nhập.

Với mục đích xây dựng câu hỏi này, chúng ta hãy giả sử rằng chúng ta đang ở trên nền tảng .NET với việc ghi nhật ký log4net nhưng hãy trả lời một cách chung chung.

Giải pháp: Dự án Windows Forms. Dự án: UI, BusinessRules, DataHandlers

Vì vậy, bạn có định viết về DataHandlers để thực hiện Thao tác dữ liệu của bạn như Tạo, Đọc, Cập nhật, Xóa trước.

Sau đó theo dõi nó với Quy tắc kinh doanh của bạn

Và sau đó UI của bạn hoặc bất kỳ hoán vị khác ở trên.

Kiểm tra ứng dụng của bạn cho chức năng.

Và sau đó bắt đầu viết Mã xử lý ngoại lệ và cuối cùng là Mã đăng nhập của bạn?

Khi nào là thời điểm thích hợp để bắt đầu viết mã Xử lý ngoại lệ của bạn?

PS: Trong cuốn sách Clean Code , họ nói Viết khối chặn thử cuối cùng của bạn trước. Điều đó, nhắc tôi đặt câu hỏi này.

Bạn viết mã xử lý ngoại lệ của mình khi bạn viết thứ gọi thứ gì đó có thể gây ra ngoại lệ.

Chẳng hạn, khi bạn viết thứ gì đó gửi dữ liệu tới mạng, bạn cũng nên viết mã xử lý thời gian chờ kết nối. Ngoại lệ liên quan trực tiếp đến những gì bạn đang làm và công việc luôn mới mẻ trong tâm trí bạn.

Mặt khác, nếu bạn đang viết một trình phân tích cú pháp làm tăng các ngoại lệ khi nó gặp một đơn vị dữ liệu giao thức không đúng định dạng, thì bạn không thể viết mã xử lý ngoại lệ cho các ngoại lệ mà trình phân tích cú pháp tạo ra . (Nhưng tất nhiên, bạn đang viết bài kiểm tra để cho biết cách thức và thời điểm và lý do trình phân tích cú pháp đưa ra ngoại lệ!)

Lý do đằng sau gợi ý viết thử bắt của bạn trước hết là hai lần: cuối cùng là để dọn sạch các tài nguyên mà chức năng tạo / tiêu thụ và viết phần bắt là một lời nhắc nhở tốt đẹp rằng các chức năng bạn gọi có thể thất bại, và bạn cần xử lý (nếu cần) những thất bại đó.

Tôi có xu hướng thêm đăng nhập sau khi thực tế. Tôi không chắc điều đó có khôn ngoan không, nhưng đó chỉ là những gì đã làm việc cho tôi. Khi tôi bắt đầu chạy thử nghiệm chấp nhận và tương tự, và bắt đầu gặp sự cố, sau đó tôi thêm ghi nhật ký để tôi có thể theo dõi lỗi. (Và sau đó tôi rời khỏi đăng nhập.)

Theo kinh nghiệm của tôi, nếu bạn không viết mã với cách xử lý lỗi và ghi nhật ký thích hợp ngay từ đầu, nó sẽ không được thực hiện do áp lực thời gian. Những nỗ lực phát triển thành công nhất mà tôi đã bắt đầu với thời gian xác định cấu trúc ứng dụng cơ bản, bao gồm tiêu chuẩn mã hóa, cách xử lý lỗi, ghi nhật ký, kiến ​​trúc cơ bản và các công cụ kiểm tra.

Mặt khác, bạn sẽ thấy rằng bạn có các tác vụ cho phiên bản 2.0 như "Cải thiện xử lý lỗi" và "tạo hệ thống ghi nhật ký". Chúng sẽ được cắt giảm theo các tính năng mới và vì bạn có "quá nhiều việc phải làm", khắc phục tất cả các lỗi đó trong các trường hợp lỗi mà bạn không nghĩ tới. (Mất mãi mãi, vì bạn không có hệ thống đăng nhập.

Phụ thuộc vào những gì bạn đang làm

cho các ngoại lệ:

Nếu bạn đang viết một cái gì đó có khả năng có lỗi hoặc một cái gì đó có điểm cấp cao nhất để cho phép ngoại lệ nổi lên để viết chúng khi bạn đi.

Nếu bạn đang viết một cái gì đó cần hiệu suất và có khả năng sai sót thấp, thì thiếu một vị trí có ý nghĩa để đặt các trình xử lý lỗi, hãy viết các trình xử lý lỗi trong đó kiểm tra chứng minh rằng bạn cần chúng.

Trong cả hai trường hợp, nếu bạn không có gì hữu ích với lỗi, hãy cân nhắc để nó nổi lên (không xử lý)

để đăng nhập:

Nếu bạn cần một dấu vết kiểm toán, bạn nên viết nhật ký trước. Nếu bạn đang để lỗi bong bóng từ đầu đến cuối, bạn cũng cần cung cấp một số ghi nhật ký ở đó để nhật ký có thể được ghi lại.

Ngoài những trường hợp đó, tôi thường chỉ thêm đăng nhập ở những nơi kiểm tra / sử dụng chứng minh điều đó là cần thiết và tôi thường đưa ra một tùy chọn để định cấu hình nó sau khi tôi hoàn thành nó.

Bạn có thể thực hiện kiểm toán và xử lý ngoại lệ như các dịch vụ. Ghi nhật ký kiểm toán cấp ứng dụng yêu cầu dữ liệu trạng thái về mỗi giao dịch kinh doanh. Khả năng giám sát một ứng dụng trong bối cảnh kinh doanh hoặc giao dịch yêu cầu giao diện giám sát trong dịch vụ để gửi tin nhắn chi tiết về trạng thái của giao dịch cụ thể đối với yêu cầu dịch vụ. Điều này đòi hỏi mỗi dịch vụ phải gửi một thông điệp trạng thái ở các bước quan trọng trong giao dịch kinh doanh. Sau đó, bạn có thể xây dựng trình xem thời gian thực để tương quan các thông báo trạng thái (dựa trên ngữ nghĩa của thông báo - ví dụ: ID giao dịch) với các dịch vụ trong ứng dụng tổng hợp. Điều này cung cấp một cái nhìn từ đầu đến cuối của giao dịch kinh doanh để quản lý SLA, theo dõi lỗi và xác định vấn đề.

Sau đó, một dịch vụ kiểm toán có thể được triển khai như một máy trạng thái có thể tiêu thụ và ghi lại các thông điệp dựa trên các tiêu chí được xác định trong cấu hình của nó. Một trình xử lý ngoại lệ chung cũng có thể sử dụng dịch vụ kiểm toán để hỗ trợ một cái nhìn tập trung về các vấn đề xảy ra trong SOA doanh nghiệp - để hỗ trợ giám sát dựa trên ngoại lệ. Bất kỳ điều kiện không nên xảy ra trong giải pháp đều được sử dụng để gửi một thông báo ngoại lệ đến bộ xử lý ngoại lệ.

Viết nó khi bạn cần, nhưng thiết kế để đưa vào từ đầu.

Nói cách khác: làm cho nó có một cách để xử lý khả năng ghi nhật ký đó và thêm chức năng đai ốc và bu lông thực tế (những thông điệp mà nó ghi lại) sau này khi có nhu cầu. Trong trường hợp ngoại lệ - thêm phần bắt (và cuối cùng nếu bạn đã hiểu) trước khi bạn viết cú ném. Điều đó sẽ giúp bạn không quên một lần và tiết kiệm cho mình một lần lặp hoặc tệ nhất là một lỗi / sự cố.