Tại sao "khúc gỗ và ném" được coi là một mô hình phản đối? [đóng cửa]

Câu hỏi này được khơi mào bởi một cuộc thảo luận xung quanh bài viết này , nơi tôi không nhận được bất kỳ câu trả lời hay ho nào.

Tại sao nên ghi lại ngoại lệ của bạn và sau đó ném lại nó (tất nhiên là giữ nguyên dấu vết ngăn xếp ban đầu) là một ý tưởng tồi nếu bạn không thể xử lý nó theo cách khác?

Tôi cho rằng câu trả lời phần lớn là vì tại sao bạn lại bắt được nó nếu bạn không thể xử lý nó? Tại sao không để bất kỳ ai có thể xử lý nó (hoặc bất cứ ai không có lựa chọn nào khác ngoài việc xử lý nó) ghi lại nó, nếu họ cảm thấy rằng nó xứng đáng với log?

Nếu bạn bắt được nó và ghi lại nó rồi ném lại, thì không có cách nào để mã ngược dòng biết rằng bạn đã ghi lại ngoại lệ và do đó, cùng một ngoại lệ có thể được ghi lại hai lần. Hoặc tệ hơn, nếu tất cả mã ngược dòng tuân theo cùng một mẫu này, thì ngoại lệ có thể được ghi lại một số lần tùy ý, một lần cho mỗi cấp trong mã quyết định bắt nó, ghi lại nó, rồi ném nó lại.

Ngoài ra, một số người có thể tranh luận rằng vì các trường hợp ngoại lệ ném và bắt là các hoạt động tương đối tốn kém, tất cả việc bắt và ném lại này không giúp ích cho hiệu suất thời gian chạy của bạn. Nó cũng không giúp mã của bạn về mặt ngắn gọn hoặc khả năng bảo trì.

Đăng nhập và ném là một mô hình tốt vì thực thể bắt và ném lại ngoại lệ có lý do để tin rằng nó chứa thông tin sẽ không được ghi vào ngăn xếp cuộc gọi - ít nhất là không theo cách mong muốn nhất. Một vài lý do khiến điều này có thể xảy ra:

1. Ngoại lệ có thể bị bắt và phát triển lại ở ranh giới lớp ứng dụng và có thể chứa thông tin đặc quyền. Sẽ là không tốt nếu lớp cơ sở dữ liệu cho phép một ngoại lệ, ví dụ: "Cố gắng thêm khóa trùng lặp 'fnord' vào trường 'người dùng'" để đến lớp ứng dụng bên ngoài (có thể hiển thị nó cho người dùng), nhưng nó có thể hữu ích cho các phần bên trong của cơ sở dữ liệu để ném một ngoại lệ như vậy và giao diện ứng dụng để bắt nó, ghi lại nó một cách an toàn và tạo lại một ngoại lệ ít mô tả hơn.
2. Ngoại lệ có thể là một ngoại lệ mà lớp bên ngoài có thể sẽ xử lý mà không cần ghi nhật ký, nhưng lớp bên trong có thể biết điều gì đó mà lớp bên ngoài không có, điều này cho thấy rằng việc ghi nhật ký có thể hữu ích. Như một ví dụ đơn giản, một lớp ứng dụng giữa có thể được lập trình để thử kết nối với một máy chủ và nếu điều đó không hiệu quả, hãy thử một lớp khác. Làm ngập nhật ký của ứng dụng với thông báo 'kết nối không thành công' trong khi máy chủ ngừng hoạt động để bảo trì có thể không hữu ích, đặc biệt là vì - từ quan điểm của ứng dụng, mọi thứ đều hoạt động tốt. Có thể hữu ích khi chuyển tiếp thông tin về lỗi kết nối đến tài nguyên ghi nhật ký được liên kết với máy chủ, sau đó có thể lọc nhật ký để tạo báo cáo về thời điểm máy chủ hoạt động lên xuống, trái ngược với nhật ký của mọi lần kết nối đơn lẻ .

Tôi đoán lý do đơn giản nhất là bạn thường có một trình xử lý cấp cao nhất làm việc này cho bạn, vì vậy không cần phải làm ô nhiễm mã với xử lý ngoại lệ này.

Lập luận về mối quan tâm xuyên suốt về cơ bản là việc xử lý các lỗi không liên quan đến bạn sẽ rất lãng phí thời gian. Tốt hơn nhiều là để lỗi nổi lên ngăn xếp cuộc gọi cho đến khi tìm thấy một trình xử lý thích hợp.

Theo tôi, thời điểm duy nhất bạn nên bắt một ngoại lệ là khi bạn có thể làm điều gì đó hữu ích với kết quả. Bắt đơn giản để ghi nhật ký không hữu ích, vì bạn có thể tập trung công việc đó lên cao hơn nữa.

Nhật ký và ném IMO rõ ràng là vi phạm Nguyên tắc Ít bất ngờ.

Nếu ngoại lệ được xử lý đúng cách thêm vào ngăn xếp cuộc gọi, nó có thể không có giá trị cho một mục nhập nhật ký lỗi. Và sau đó thật khó hiểu khi tìm thấy một mục nhật ký lỗi.