Là xử lý ngoại lệ là một mối quan tâm xuyên suốt?

Tôi không thấy nhiều sự khác biệt giữa các mối quan tâm về xử lý ngoại lệ và đăng nhập rằng cả hai đều là mối quan tâm xuyên suốt. Bạn nghĩ sao? Không nên tự mình xử lý nó chứ không nên xen kẽ với logic cốt lõi mà một phương thức đang thực hiện?

EDIT : Điều tôi đang cố gắng nói, theo tôi, việc triển khai phương thức chỉ nên chứa logic cho đường dẫn thực hiện thành công và các ngoại lệ nên được xử lý ở nơi khác. Đây không phải là về ngoại lệ được kiểm tra / không được kiểm tra.

Ví dụ: một ngôn ngữ có thể xử lý các ngoại lệ theo cách được kiểm tra đầy đủ bằng cách sử dụng các cấu trúc như thế này:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

Trong ngôn ngữ khái niệm trên, chương trình sẽ không được biên dịch nếu không có FileReader trình xử lý , vì readFile của FileReader lớp không ném ngoại lệ. Vì vậy, bằng cách khai báo FileReader trình xử lý , trình biên dịch có thể đảm bảo rằng nó đang được xử lý và sau đó chương trình sẽ biên dịch.

Bằng cách này, chúng tôi có các vấn đề ngoại lệ được kiểm tra và không được kiểm tra tốt nhất: mạnh mẽ và dễ đọc.

Trong một số trường hợp có

Trong trường hợp bạn có một ngoại lệ mà bạn muốn đăng nhập (mà tôi cho là gần như luôn luôn) thì có, ngoại lệ đó được gắn với một mối quan tâm xuyên suốt.

Hầu hết thời gian không

Tuy nhiên, lấy ví dụ của SocketListener, nếu socketlistener ném ngoại lệ do đầu kia bị rớt kết nối, thì đây sẽ là hành vi được dự đoán trước và do đó ứng dụng sẽ hành động theo các trường hợp gây ra ngoại lệ. Đây không phải là điều mà một khía cạnh chung nên xử lý, và vì vậy không nên là mối quan tâm xuyên suốt.

Xác định mối quan tâm xuyên suốt

Nếu bạn đang sao chép cùng một mã nhiều lần thì nó cần phải được trừu tượng hóa. Nếu sự trừu tượng thúc đẩy chính nó đến nhiều lớp, nó có thể là một mối quan tâm xuyên suốt. Chỉ sau đó nó nên được xem xét.

Ghi nhật ký là tùy chọn. Xử lý các trường hợp ngoại lệ không.

Ghi nhật ký khá chung chung và trong khi nó lấy nguồn từ logic cụ thể, nó cung cấp cho người tiêu dùng chung. Các ngoại lệ luôn đặc trưng cho logic và một số mã có kiến ​​thức về logic đó phải xử lý mớ hỗn độn mà nó tạo ra.

Ít nhất trong việc sử dụng hạn chế của tôi trong hai điều đó có nghĩa là hai mục tiêu được xử lý tốt nhất theo những cách khác nhau và không dưới cùng một chiếc ô thiết kế.

Tôi xem việc xử lý ngoại lệ là mối quan tâm xuyên suốt đối với một số loại ngoại lệ nhất định. Có những ngoại lệ cục bộ mà chỉ có mã gọi ngay lập tức có thể xử lý chính xác. Một ví dụ có thể là một ngoại lệ cơ sở dữ liệu khi cố gắng thực hiện một truy vấn. Nhưng cũng có những trường hợp ngoại lệ có thể và nên được xử lý trên toàn cầu. Một ví dụ có thể là một ngoại lệ liên quan đến việc thiếu thông tin bảo mật (buộc người dùng phải đăng nhập lại). Hoặc ít nhất bạn cần một trình xử lý toàn cầu trong trường hợp một ngoại lệ trượt qua mã cụ thể hơn, để giải thích cho người dùng những gì họ nên làm để khởi động lại hoặc gửi nhật ký tới CNTT hoặc đại loại như thế. Đối với các loại ngoại lệ được xử lý trên toàn cầu, đây là một mối quan tâm xuyên suốt.

Tôi nghĩ rằng mối quan hệ này liên quan đến vấn đề trừu tượng bị rò rỉ.

Nhiều trường hợp ngoại lệ nên được bắt và rút lại khi chúng di chuyển qua các lớp trừu tượng. Việc ném lại phải ném ngoại lệ theo một hình thức mới, phù hợp với sự trừu tượng đang thực hiện việc ném lại, để nó có ý nghĩa như là một phần của giao diện. Nói cách khác, các trường hợp ngoại lệ từ mức độ trừu tượng thấp hơn nên được dịch thành dạng trừu tượng hiện tại để mức độ trừu tượng cao hơn không cần biết về mức độ thấp hơn, thậm chí hoàn toàn là xử lý ngoại lệ.

Tuy nhiên, "nguyên tắc trừu tượng rò rỉ" là một vấn đề. Một số trường hợp ngoại lệ không thể được dịch sang một hình thức có ý nghĩa trong lớp trừu tượng tiếp theo.

Một ngoại lệ liên quan đến hệ thống tập tin mạng là một ví dụ đơn giản. Lỗi mạng không thể được thể hiện bằng các thuật ngữ có ý nghĩa đối với sự trừu tượng hóa "tệp" hoặc, nếu có, sự trừu tượng đó đã không thực sự trừu tượng hóa hoàn toàn tất cả các chi tiết liên quan đến việc thực hiện xử lý tệp.

Do đó, một lỗi mạng sẽ rò rỉ ra khỏi sự trừu tượng mạng cơ bản và do đó phải là mối quan tâm xuyên suốt trong phần còn lại của mã.

Điều này không phải là duy nhất cho các ngoại lệ, mặc dù. Tất cả các mã lỗi giá trị trả về cho API tệp không thực sự liên quan đến trừu tượng tệp, nhưng thay vào đó, chi tiết đĩa cứng hoặc mạng hoặc bất kỳ lỗi nào đều giống nhau ở một dạng khác, ngụ ý rằng lỗi đĩa cứng và lỗi mạng vv là những mối quan tâm xuyên suốt bất kể những thất bại đó được báo cáo như thế nào.