TL; DR - Không , bạn không nên bỏ qua các ngoại lệ một cách lặng lẽ.
Hãy xem xét các giả định.
- Niềm tin mù quáng của bạn
Tôi đã học cách tin tưởng rằng nhiều quyết định trong .NET được đưa ra bởi những người thực sự biết họ đang làm gì và thường có một lý do rất chính đáng đằng sau những điều họ quyết định. Nhưng cái này thoát khỏi tôi.
MS có một số người thực sự xuất sắc trong đội ngũ nhân viên, không có nghi ngờ. Họ cũng có một số nhà quản lý và giám đốc điều hành ... không biết gì và luôn đưa ra những quyết định tồi tệ. Nhiều như chúng tôi muốn tin vào câu chuyện cổ tích của nhà khoa học am hiểu kỹ thuật thúc đẩy sự phát triển sản phẩm, thực tế còn nghiệt ngã hơn nhiều.
Quan điểm của tôi, nếu bản năng của bạn nói với bạn điều gì đó có thể sai thì có một cơ hội tốt (và tiền lệ trong quá khứ) rằng nó sai.
- Đây là một vấn đề kỹ thuật
Làm thế nào để xử lý các trường hợp ngoại lệ trong trường hợp này là một quyết định yếu tố con người, không phải là một quyết định kỹ thuật. Một cách lỏng lẻo, một ngoại lệ là một lỗi. Trình bày lỗi, ngay cả khi được định dạng kém, cung cấp thông tin quan trọng cho người dùng cuối. Cụ thể, một cái gì đó đã đi sai.
Hãy xem xét cuộc trò chuyện giả thuyết này giữa người dùng cuối và nhà phát triển.
Người dùng: Ứng dụng bị hỏng.
Dev: Cái gì đã hỏng?
Thành viên: Tôi không biết, tôi bấm vào nút và không có gì xảy ra.
Dev: Ý bạn là gì khi không có gì xảy ra?
Người dùng: Nhìn, tôi bấm, tôi chờ, và tôi đợi, và tôi chờ, và không có gì ... rõ ràng là nó đã bị hỏng.
Nhà phát triển giả thuyết nghèo nàn của chúng tôi bây giờ phải tìm ra điều gì đã xảy ra trong chuỗi sự kiện. Nó ở đâu?
Thông báo xử lý sự kiện -> Thường xuyên để xử lý sự kiện -> Phương thức được kích hoạt bởi trình xử lý -> bắt đầu cuộc gọi không đồng bộ -> 7 lớp của mạng OSI -> truyền vật lý -> sao lưu 7 lớp của mạng OSI -> dịch vụ nhận -> phương thức được gọi bởi dịch vụ -> ... -> trả lời trả lời được gửi bởi dịch vụ -> .... -> nhận asynch -> xử lý trả lời asynch -> ...
Và xin lưu ý rằng tôi đã theo dõi một số đường dẫn lỗi tiềm ẩn ở đó.
Sau khi giải quyết một số giả định cơ bản, tôi nghĩ nó trở nên rõ ràng hơn tại sao lặng lẽ ngăn chặn các ngoại lệ là một ý tưởng tồi. Một thông báo lỗi ngoại lệ và liên quan là một chỉ báo quan trọng cho người dùng rằng đã xảy ra sự cố. Ngay cả khi tin nhắn là vô nghĩa đối với người dùng cuối, thông tin được nhúng có thể hữu ích cho Nhà phát triển để hiểu những gì đã sai. Nếu họ may mắn, thông điệp thậm chí sẽ dẫn đến giải pháp.
Tôi nghĩ một phần của vấn đề ở đây là một ngoại lệ được xử lý không chính xác sẽ làm hỏng ứng dụng của bạn. Bằng cách loại bỏ các ngoại lệ, ứng dụng sẽ không gặp sự cố. Có một số giá trị cho điều này mặc dù quan điểm không đồng bộ là cho phép ứng dụng tiếp tục hoạt động trong khi dữ liệu đang được truy xuất. Đó không phải là một phần mở rộng hợp lý để nói rằng nếu bạn có thể tiếp tục vận hành trong khi chờ kết quả thì lỗi truy xuất cũng không làm hỏng ứng dụng - cuộc gọi async được tuyên bố là không đủ quan trọng để kết thúc ứng dụng.
Vì vậy, nó là một giải pháp, nhưng nó giải quyết vấn đề sai. Sẽ không mất nhiều công sức để cung cấp trình bao bọc cho việc xử lý ngoại lệ để ứng dụng có thể tiếp tục chạy. Ngoại lệ bị bắt, thông báo lỗi được ném lên màn hình hoặc đăng nhập và ứng dụng được phép tiếp tục chạy. Việc loại bỏ ngoại lệ ngụ ý rằng bỏ qua lỗi sẽ là A-OK và thử nghiệm của bạn sẽ đảm bảo các ngoại lệ không bao giờ thoát ra khỏi trường.
Vì vậy, đánh giá cuối cùng của tôi là đây là một nỗ lực nửa vời trong việc giải quyết vấn đề được tạo ra bằng cách đẩy mọi người vào một mô hình không đồng bộ khi họ không sẵn sàng chuyển suy nghĩ của mình sang phương pháp đó.