Tôi đã được trao "cơ hội" để cứu vãn một số dự án và giám đốc điều hành đã thay thế toàn bộ nhóm phát triển vì ứng dụng có quá nhiều lỗi và người dùng đã mệt mỏi với các vấn đề và chạy xung quanh. Các cơ sở mã này đều có xử lý lỗi tập trung ở cấp ứng dụng như câu trả lời được bình chọn hàng đầu mô tả. Nếu câu trả lời đó là cách thực hành tốt nhất tại sao nó không hoạt động và cho phép nhóm nhà phát triển trước giải quyết vấn đề? Có lẽ đôi khi nó không hoạt động? Các câu trả lời ở trên không đề cập đến việc các nhà phát triển dành bao lâu để khắc phục các sự cố đơn lẻ. Nếu thời gian để giải quyết các vấn đề là số liệu chính, mã thiết bị với các khối try..catch là cách thực hành tốt hơn.
Làm thế nào để nhóm của tôi sửa chữa các vấn đề mà không thay đổi đáng kể giao diện người dùng? Đơn giản, mọi phương thức đều được gắn với try..catch bị chặn và mọi thứ được ghi lại tại điểm không thành công với tên phương thức, các giá trị tham số phương thức được nối vào một chuỗi được gửi cùng với thông báo lỗi, thông báo lỗi, tên ứng dụng, ngày, và phiên bản. Với thông tin này, các nhà phát triển có thể chạy các phân tích về các lỗi để xác định ngoại lệ xảy ra nhiều nhất! Hoặc không gian tên có số lỗi cao nhất. Nó cũng có thể xác nhận rằng một lỗi xảy ra trong một mô-đun được xử lý đúng cách và không phải do nhiều nguyên nhân.
Một lợi ích chuyên nghiệp khác của việc này là các nhà phát triển có thể đặt một điểm dừng trong phương pháp ghi nhật ký lỗi và với một điểm dừng và một lần bấm nút gỡ lỗi "bước ra", họ đang ở phương thức không thể truy cập đầy đủ vào thực tế đối tượng tại điểm thất bại, thuận tiện có sẵn trong cửa sổ ngay lập tức. Nó làm cho nó rất dễ dàng để gỡ lỗi và cho phép kéo thực thi trở lại bắt đầu phương thức để nhân đôi vấn đề để tìm dòng chính xác. Có xử lý ngoại lệ tập trung cho phép nhà phát triển sao chép ngoại lệ trong 30 giây không? Không.
Câu lệnh "Một phương thức chỉ nên bắt một ngoại lệ khi nó có thể xử lý nó theo một cách hợp lý nào đó." Điều này ngụ ý rằng các nhà phát triển có thể dự đoán hoặc sẽ gặp phải mọi lỗi có thể xảy ra trước khi phát hành. Nếu đây là mức cao nhất, trình xử lý ngoại lệ ứng dụng sẽ không cần thiết và sẽ không có thị trường cho Tìm kiếm đàn hồi và đăng nhập.
Cách tiếp cận này cũng cho phép các nhà phát triển tìm và khắc phục các vấn đề không liên tục trong sản xuất! Bạn có muốn gỡ lỗi mà không có trình sửa lỗi trong sản xuất không? Hay bạn muốn nhận cuộc gọi và nhận email từ những người dùng khó chịu? Điều này cho phép bạn khắc phục sự cố trước khi bất kỳ ai khác biết và không phải gửi email, IM hoặc Slack với sự hỗ trợ vì mọi thứ cần thiết để khắc phục sự cố đều ở ngay đó. 95% các vấn đề không bao giờ cần phải sao chép.
Để hoạt động chính xác, nó cần được kết hợp với ghi nhật ký tập trung để có thể nắm bắt không gian tên / mô-đun, tên lớp, phương thức, đầu vào và thông báo lỗi và lưu trữ trong cơ sở dữ liệu để có thể tổng hợp để làm nổi bật phương thức nào thất bại nhất để có thể cố định trước.
Đôi khi, các nhà phát triển chọn cách ném ngoại lệ lên ngăn xếp từ khối bắt nhưng cách tiếp cận này chậm hơn 100 lần so với mã thông thường không ném. Bắt và phát hành với đăng nhập được ưa thích.
Kỹ thuật này đã được sử dụng để nhanh chóng ổn định một ứng dụng thất bại mỗi giờ đối với hầu hết người dùng trong một công ty Fortune 500 được phát triển bởi 12 Dev trong hơn 2 năm. Sử dụng 3000 ngoại lệ khác nhau này đã được xác định, sửa chữa, thử nghiệm và triển khai trong 4 tháng. Điều này tính trung bình cho một sửa chữa trung bình cứ sau 15 phút trong 4 tháng.
Tôi đồng ý rằng không có gì thú vị khi nhập mọi thứ cần thiết vào công cụ mã và tôi không muốn nhìn vào mã lặp đi lặp lại, nhưng thêm 4 dòng mã vào mỗi phương thức là điều đáng giá trong thời gian dài.