Hậu tố Ngoại lệ về ngoại lệ trong java

Việc chỉ định một hậu tố của Ngoại lệ đối với các lớp ngoại lệ có cảm giác giống như mùi mã đối với tôi (Thông tin dư thừa - phần còn lại của tên ngụ ý trạng thái lỗi và nó thừa hưởng từ Ngoại lệ). Tuy nhiên, dường như mọi người đều làm điều đó và nó có vẻ là thực hành tốt.

Tôi đang tìm hiểu để hiểu tại sao đây là thực hành tốt.

Tôi đã thấy và đọc câu hỏi tại sao các ngoại lệ thường có ngoại lệ hậu tố trong tên lớp

Câu hỏi dành cho PHP và trong khi các câu trả lời có thể hợp lệ cho Java. Có bất kỳ đối số khác hoặc nó thực sự đơn giản như phân biệt rõ ràng chúng?

Nếu chúng ta lấy các ví dụ từ câu hỏi trước - thực sự có thể có các lớp trong java với tên FileNoFoundkhông phải là ngoại lệ không? Nếu có thể, nó có bảo đảm với nó Exceptionkhông?

Nhìn vào một hệ thống phân cấp nhanh chóng trong nhật thực Exception, chắc chắn, phần lớn trong số chúng có hậu tố ngoại lệ, nhưng có một vài trường hợp ngoại lệ. javassistlà một ví dụ về một thư viện dường như có một vài ngoại lệ mà không có hậu tố - ví dụ BadByteCode, BadHttpRequestv.v.

BouncyCastle là một lib khác với các ngoại lệ như CompileError

Tôi đã loay hoay một chút cũng như có ít thông tin về chủ đề này.

Câu trả lời của Landei là một câu trả lời hay, nhưng cũng có câu trả lời về ngữ pháp. Tên lớp nên là danh từ . "OutOfMemory" là gì? "FileNotFound" là gì? Nếu bạn nghĩ "Exception" là danh từ, thì mô tả là tính từ chỉ định nó. Nó không chỉ là bất kỳ Exception, đó là một FileNotFoundException. Bạn không cần phải bắt OutOfMemorynhiều hơn bạn đến cửa hàng để mua "màu xanh".

Điều này cũng hiển thị nếu bạn đọc mã của mình dưới dạng câu: " Tryđang làm ... và catch OutOfMemory Exceptions"

Tôi nghĩ rằng các trường hợp ngoại lệ (và lỗi và về mặt lý thuyết khác Throwable) khác với những thứ như giao diện hoặc enum (thường không được sử dụng như hậu tố): Chúng thường có mục đích rất rõ ràng và hạn chế, chúng được sử dụng với các cấu trúc ngôn ngữ chuyên ngành ( try, catch, throw, throws) và làm theo quy tắc đặc biệt (ví dụ như kiểm tra vs trường hợp ngoại lệ được kiểm soát, không có generics). Theo một cách nào đó, chúng không chỉ là các lớp xảy ra được sử dụng như ngoại lệ, mà là một cơ chế ngoại lệ được thực hiện bằng phương tiện của các lớp.

Vì vậy, nếu bạn xử lý một ngoại lệ và không nhận ra nó như vậy, thường thì có gì đó không đúng (một lần nữa không phải là trường hợp đối với những thứ như enums hoặc giao diện). Vì vậy, tôi nghĩ rằng những khác biệt này đối với các lớp "bình thường" là đủ lớn để gọi cho một đầu mối trực quan.

Tuy nhiên, dường như mọi người đều làm điều đó và nó có vẻ là thực hành tốt.

Vâng, tất cả mọi người thực sự làm điều đó, vì vậy nó là một thực hành, nhưng nó vẫn tốt? Một số người đang đặt câu hỏi rằng:

• http://mnapoli.fr/approaching-coding-style-rationally/ (Hậu tố ngoại lệ § bối cảnh: php)
• video được liên kết, https://vimeo.com/album/2661665/video/74316116 (bỏ qua đến 53:00, bối cảnh: php), truyền cảm hứng cho bài viết và đưa ra quan điểm rằng mỗi khi bạn sử dụng một ngoại lệ, bạn có một từ khóa đã cho thấy nó là một ngoại lệ gần đó
• http://verraes.net/2013/10/verbs-in- class-name / cho thấy cách phát biểu trong câu trả lời của @Bobson có thể không tuyệt đối và đưa ra quan điểm rằng đôi khi hậu tố là tốt, cho ứng dụng hoặc ngoại lệ ở cấp cơ sở hạ tầng và đôi khi bạn nên cố gắng lưu các ký tự được lấy bởi hậu tố dài này để diễn tả một cái gì đó chính xác và có ý nghĩa hơn. Điểm này chỉ có ý nghĩa nếu bạn sử dụng một ngôn ngữ trong đó văn hóa là sử dụng ngoại lệ cho các vi phạm quy tắc kinh doanh.
• các SO tạo đường link mà bạn cung cấp làm cho điểm về xung đột tên, nhưng bây giờ, chúng tôi có không gian tên, chúng ta không?