Trong Java, các ngoại lệ được kiểm tra là tốt để làm gì? [đóng cửa]

Các ngoại lệ được kiểm tra của Java đã nhận được một số báo chí xấu trong những năm qua. Một dấu hiệu cho biết đó thực sự là ngôn ngữ duy nhất trên thế giới có chúng (thậm chí không phải các ngôn ngữ JVM khác như Groovy và Scala). Các thư viện Java nổi bật như Spring và Hibernate cũng không sử dụng chúng.

Cá nhân tôi đã tìm thấy một cách sử dụng cho họ ( theo logic kinh doanh giữa các lớp), nhưng nếu không thì tôi khá là ngoại lệ chống kiểm tra.

Có cách sử dụng nào khác mà tôi không nhận ra không?

Trước hết, giống như bất kỳ mô hình lập trình nào khác, bạn cần thực hiện đúng để nó hoạt động tốt.

Đối với tôi , lợi thế của các ngoại lệ được kiểm tra là các tác giả của thư viện thời gian chạy Java ALREADY đã quyết định cho tôi những vấn đề phổ biến mà tôi có thể dự kiến ​​có thể xử lý tại điểm gọi (trái ngược với bản in bắt cấp cao nhất- khối chết) và xem xét càng sớm càng tốt làm thế nào để xử lý những vấn đề này.

Tôi thích các ngoại lệ được kiểm tra vì chúng làm cho mã của tôi mạnh mẽ hơn bằng cách buộc tôi phải suy nghĩ về việc khôi phục lỗi càng sớm càng tốt.

Nói chính xác hơn, với tôi điều này làm cho mã của tôi mạnh mẽ hơn vì nó buộc tôi phải xem xét các trường hợp góc lạ từ rất sớm trong quá trình thay vì nói "Rất tiếc, mã của tôi không xử lý nếu tệp chưa tồn tại" dựa trên một lỗi trong sản xuất, sau đó bạn phải xử lý lại mã của mình để xử lý. Thêm xử lý lỗi vào mã hiện tại có thể là một nhiệm vụ không hề nhỏ - và do đó tốn kém - khi đạt được bảo trì thay vì chỉ thực hiện ngay từ đầu.

Có thể tệp bị thiếu là một thứ gây tử vong và sẽ khiến chương trình gặp sự cố, nhưng sau đó bạn đưa ra quyết định đó với

} catch (FileNotFoundException e) {
  throw new RuntimeException("Important file not present", e);
}

Điều này cũng cho thấy một tác dụng phụ rất quan trọng. Nếu bạn bọc một ngoại lệ, bạn có thể thêm một lời giải thích trong dấu vết ngăn xếp ! Điều này cực kỳ mạnh mẽ bởi vì bạn có thể thêm thông tin về ví dụ như tên của tệp bị thiếu hoặc các tham số được truyền cho phương thức này hoặc thông tin chẩn đoán khác và thông tin đó có ngay trong dấu vết ngăn xếp thường là điều duy nhất bạn nhận được khi một chương trình đã bị hỏng.

Mọi người có thể nói "chúng tôi chỉ có thể chạy trình gỡ lỗi này để sao chép", nhưng tôi đã thấy rằng các lỗi sản xuất rất thường xuyên không thể được sao chép sau đó và chúng tôi không thể chạy trình gỡ lỗi trong sản xuất trừ trường hợp rất khó chịu khi công việc của bạn bị đe dọa.

Càng nhiều thông tin trong theo dõi ngăn xếp của bạn, thì tốt hơn. Các trường hợp ngoại lệ được kiểm tra giúp tôi có được thông tin đó trong đó và sớm.

EDIT: Điều này cũng dành cho các nhà thiết kế thư viện. Một thư viện tôi sử dụng hàng ngày chứa nhiều, nhiều trường hợp ngoại lệ được kiểm tra có thể được thiết kế tốt hơn nhiều khiến việc sử dụng ít tẻ nhạt hơn.

Bạn đã có hai câu trả lời hay giải thích những gì đã được kiểm tra ngoại lệ trong thực tế. (+1 cho cả hai.) Nhưng cũng đáng để xem xét những gì họ dự định trong lý thuyết, bởi vì ý định thực sự đáng giá.

Các trường hợp ngoại lệ được kiểm tra thực sự nhằm mục đích làm cho ngôn ngữ trở nên an toàn hơn. Hãy xem xét một phương pháp đơn giản như phép nhân số nguyên. Bạn có thể nghĩ rằng loại kết quả của phương pháp này sẽ là một số nguyên, nhưng, nói đúng ra, kết quả là một số nguyên hoặc một ngoại lệ tràn. Việc xem xét kết quả số nguyên của chính nó là kiểu trả về của phương thức không thể hiện phạm vi đầy đủ của hàm.

Nhìn thấy trong ánh sáng này, không hoàn toàn đúng khi nói rằng các ngoại lệ được kiểm tra đã không tìm được đường đến các ngôn ngữ khác. Họ đã không lấy hình thức mà Java đã sử dụng. Trong các ứng dụng Haskell, người ta thường sử dụng các kiểu dữ liệu đại số để phân biệt giữa việc hoàn thành thành công và không thành công của hàm. Mặc dù đây không phải là một ngoại lệ, nhưng mọi người đều có ý định giống như một ngoại lệ được kiểm tra; nó là một API được thiết kế để buộc người tiêu dùng API xử lý cả thành công trong trường hợp không thành công, ví dụ:

data Foo a =
     Success a
   | DidNotWorkBecauseOfA
   | DidNotWorkBecauseOfB

Điều này nói với lập trình viên rằng hàm có hai kết quả có thể bổ sung bên cạnh thành công.

IMO, các trường hợp ngoại lệ được kiểm tra là một triển khai thiếu sót của những gì có thể là một ý tưởng khá hay (trong hoàn cảnh hoàn toàn khác - nhưng thực sự thậm chí không phải là một ý tưởng tốt trong hoàn cảnh hiện tại).

Ý tưởng tốt là sẽ rất tốt nếu trình biên dịch xác minh rằng tất cả các ngoại lệ mà một chương trình có tiềm năng để ném sẽ bị bắt. Việc triển khai thiếu sót là để làm điều đó, Java buộc bạn phải xử lý ngoại lệ trực tiếp trong bất kỳ lớp nào gọi bất kỳ thứ gì được tuyên bố để ném ngoại lệ được kiểm tra. Một trong những ý tưởng cơ bản nhất (và ưu điểm) của xử lý ngoại lệ là trong trường hợp có lỗi, nó cho phép các lớp mã trung gian không liên quan đến một lỗi cụ thể, hoàn toàn bỏ qua sự tồn tại của nó. Các ngoại lệ được kiểm tra (như được triển khai trong Java) không cho phép điều đó, do đó phá hủy lợi thế chính (chính?) Của việc xử lý ngoại lệ để bắt đầu.

Về lý thuyết, họ có thể đã làm cho các ngoại lệ được kiểm tra trở nên hữu ích bằng cách chỉ thực thi chúng trên cơ sở toàn chương trình - nghĩa là, trong khi "xây dựng" chương trình, xây dựng một cây gồm tất cả các đường dẫn điều khiển trong chương trình. Các nút khác nhau trong cây sẽ được chú thích với 1) ngoại lệ mà chúng có thể tạo và 2) ngoại lệ mà chúng có thể bắt được. Để đảm bảo chương trình là chính xác, sau đó bạn đi trên cây, xác minh rằng mọi ngoại lệ được ném ở bất kỳ cấp độ nào trên cây đều bị bắt ở cấp cao hơn trong cây.

Lý do họ không làm điều đó (dù sao tôi cũng đoán vậy) là vì làm như vậy sẽ rất khó khăn - thực tế, tôi nghi ngờ bất kỳ ai đã viết một hệ thống xây dựng có thể làm điều đó cho bất cứ điều gì nhưng cực kỳ đơn giản (giáp với "đồ chơi ") ngôn ngữ / hệ thống. Đối với Java, những thứ như tải lớp động khiến nó thậm chí còn khó khăn hơn trong nhiều trường hợp khác. Tồi tệ hơn, (không giống như C) Java không (ít nhất là bình thường) được biên dịch / liên kết tĩnh với một tệp thực thi. Điều đó có nghĩa là không có gì trong hệ thống thực sự có nhận thức toàn cầu để thậm chí cố gắng thực hiện loại thực thi này cho đến khi người dùng cuối thực sự bắt đầu tải chương trình để chạy nó.

Thực thi tại thời điểm đó là không thực tế vì một vài lý do. Trước hết, thậm chí tốt nhất là nó sẽ kéo dài thời gian khởi động, vốn đã là một trong những khiếu nại lớn nhất, phổ biến nhất về Java. Thứ hai, để làm được nhiều điều tốt, bạn thực sự cần phát hiện sớm vấn đề đủ để lập trình viên khắc phục nó. Khi người dùng đang tải chương trình, đã quá muộn để làm rất tốt - lựa chọn duy nhất của bạn tại thời điểm đó là bỏ qua vấn đề hoặc từ chối tải / chạy chương trình, trong trường hợp có thể có ngoại lệ Điều đó đã không bị bắt.

Vì chúng là, các ngoại lệ được kiểm tra còn tệ hơn vô dụng, nhưng các thiết kế thay thế cho các ngoại lệ được kiểm tra thậm chí còn tồi tệ hơn. Mặc dù ý tưởng cơ bản cho các ngoại lệ được kiểm tra có vẻ như là một ý tưởng tốt, nhưng nó thực sự không tốt lắm và tình cờ là một sự phù hợp đặc biệt kém cho Java. Đối với một cái gì đó như C ++, thường được biên dịch / liên kết thành một tệp thực thi hoàn chỉnh không có gì giống như tải lớp phản chiếu / lớp động, bạn sẽ có cơ hội hơn một chút (mặc dù, khá thẳng thắn, thậm chí sau đó thực thi chúng một cách chính xác mà không cần loại lộn xộn tương tự nguyên nhân hiện tại trong Java vẫn có thể vượt ra ngoài trạng thái hiện đại).

Chúng thực sự tốt cho các lập trình viên gây phiền nhiễu và khuyến khích nuốt ngoại lệ. Một nửa điểm của các trường hợp ngoại lệ là để bạn có cách xử lý lỗi mặc định và không phải suy nghĩ về việc lan truyền rõ ràng các điều kiện lỗi mà bạn không thể xử lý. (Mặc định lành mạnh là nếu bạn không bao giờ xử lý lỗi ở bất kỳ đâu trong mã của mình, bạn đã khẳng định một cách hiệu quả rằng điều đó không thể xảy ra và được để lại một lối thoát lành mạnh và dấu vết ngăn xếp nếu bạn sai.) điều này. Họ cảm thấy rất giống như phải tuyên truyền lỗi một cách rõ ràng trong C.

Tôi nghĩ thật công bằng khi nói rằng các ngoại lệ được kiểm tra là một chút thử nghiệm thất bại. Họ đã sai ở đâu là họ đã phá vỡ layering:

• Mô-đun A có thể được xây dựng trên đầu Mô-đun B, trong đó
• Mô-đun B có thể được xây dựng trên đỉnh Mô-đun C.
• Mô-đun C có thể biết cách xác định lỗi và
• Mô-đun A có thể biết cách xử lý lỗi.

Sự tách biệt tốt đẹp của mối quan tâm đã bị phá vỡ, bởi vì bây giờ kiến ​​thức về các lỗi có thể bị giới hạn ở A và C giờ phải được phân tán trên B.

Có một cuộc thảo luận tốt đẹp về các ngoại lệ được kiểm tra trên Wikipedia.

Và Bruce Eckel cũng có một bài viết hay về nó. Đây là một trích dẫn:

[T] anh ta càng có nhiều quy tắc ngẫu nhiên mà bạn chồng lên lập trình viên, các quy tắc không liên quan gì đến việc giải quyết vấn đề trong tay, lập trình viên có thể tạo ra càng chậm. Và điều này dường như không phải là một yếu tố tuyến tính, mà là một yếu tố theo cấp số nhân

Tôi tin cho trường hợp của C ++, nếu tất cả các phương thức đều có throwsmệnh đề đặc tả, thì bạn có thể có một số tối ưu hóa tốt. Mặc dù vậy, tôi không tin rằng Java có thể có những lợi thế đó bởi vì RuntimeExceptionskhông được kiểm tra. Một JIT hiện đại nên có thể tối ưu hóa mã tốt.

Một tính năng hay của AspectJ là làm mềm ngoại lệ: Bạn có thể biến các ngoại lệ được kiểm tra thành các ngoại lệ không được kiểm tra, đặc biệt để tăng cường phân lớp.

Có lẽ thật mỉa mai khi Java đã trải qua tất cả những rắc rối này, khi nó có thể đã được kiểm tra nullthay thế, điều này có thể có giá trị hơn nhiều .

Tôi yêu ngoại lệ.

Tôi, tuy nhiên, liên tục bị bối rối bởi việc sử dụng sai của họ.

1. Đừng sử dụng chúng để xử lý dòng chảy. Bạn không muốn mã cố gắng làm điều gì đó và sử dụng ngoại lệ làm trình kích hoạt để làm việc khác thay vì vì Ngoại lệ là các đối tượng cần được tạo và sử dụng bộ nhớ, v.v. chỉ vì bạn không thể bận tâm viết một số loại if () kiểm tra trước khi bạn thực hiện cuộc gọi của bạn. Điều đó chỉ lười biếng và mang đến cho Exception vinh quang một cái tên xấu.

2. Đừng nuốt chúng. Không bao giờ. Trong mọi trường hợp. Như một mức tối thiểu tuyệt đối, bạn dán một cái gì đó vào tệp nhật ký của mình để chỉ ra rằng Ngoại lệ đã xảy ra. Cố gắng theo dõi theo cách của bạn thông qua mã nuốt các ngoại lệ là một cơn ác mộng. Một lần nữa, hãy nguyền rủa bạn ngoại lệ - những kẻ nuốt chửng vì đã khiến cho Ngoại lệ hùng mạnh trở nên bất đồng!

3. Đừng đối xử với Ngoại lệ với chiếc mũ OO của bạn. Tạo các đối tượng Ngoại lệ của riêng bạn với hệ thống phân cấp có ý nghĩa. Lớp logic kinh doanh của bạn và ngoại lệ của bạn trong tay. Tôi đã từng thấy rằng nếu tôi bắt đầu vào một khu vực mới của một hệ thống, tôi sẽ thấy cần phải phân loại Ngoại lệ trong vòng nửa giờ mã hóa, vì vậy những ngày này tôi bắt đầu bằng cách viết các lớp Ngoại lệ.

4. Nếu bạn đang viết các đoạn mã 'khung', hãy đảm bảo tất cả các giao diện ban đầu của bạn được viết để đưa ra Ngoại lệ mới của riêng bạn khi thích hợp ... và đảm bảo rằng các lập trình viên của bạn có một số mã mẫu xung quanh vị trí cần làm khi mã của họ ném IOException nhưng giao diện họ đang viết muốn ném ra 'Báo cáoApplicationException'.

Khi bạn đã tìm hiểu cách làm cho Ngoại lệ hoạt động cho bạn, bạn sẽ không bao giờ nhìn lại.

Các trường hợp ngoại lệ được kiểm tra cũng có trong ADA.

(Cảnh báo, bài đăng này chứa niềm tin được tổ chức mạnh mẽ mà bạn có thể tìm thấy đối đầu.)

Các lập trình viên không thích họ và phàn nàn, hoặc viết mã nuốt ngoại lệ.

Các trường hợp ngoại lệ được kiểm tra tồn tại bởi vì mọi thứ không chỉ không hoạt động, bạn có thể thực hiện phân tích hiệu ứng / chế độ thất bại và xác định trước điều này.

Đọc tệp có thể thất bại. Các cuộc gọi RPC có thể thất bại. Mạng IO có thể thất bại. Dữ liệu có thể được định dạng sai khi phân tích cú pháp.

"Con đường hạnh phúc" cho mã rất dễ dàng.

Tôi biết một anh chàng ở trường đại học có thể viết mã "con đường hạnh phúc" tuyệt vời. Không có trường hợp cạnh bao giờ làm việc. Ngày nay, anh ấy làm Python cho một công ty nguồn mở. Nuff nói.

Nếu bạn không muốn xử lý các trường hợp ngoại lệ được kiểm tra, điều bạn thực sự nói là

While I'm writing this code, I don't want to consider obvious failure modes.

The User will just have to like the program crashing or doing weird things.

But that's okay with me because 

I'm so much more important than the people who will have to use the software

in the real, messy, error-prone world.

After all, I write the code once, you use it all day long.

Vì vậy, các ngoại lệ được kiểm tra sẽ không được các lập trình viên yêu thích, bởi vì nó có nghĩa là nhiều công việc hơn.

Tất nhiên, những người khác có thể muốn công việc đó được thực hiện.

Họ có thể đã muốn câu trả lời đúng ngay cả khi máy chủ tệp bị lỗi / thanh USB bị chết.

Đó là một niềm tin kỳ lạ trong cộng đồng lập trình rằng bạn nên sử dụng ngôn ngữ lập trình giúp cuộc sống của bạn dễ dàng hơn, mà bạn thích, khi công việc của bạn là viết phần mềm. Công việc của bạn là giải quyết vấn đề của ai đó, không cho phép bạn tham gia vào chương trình ngẫu hứng Jazz có lập trình.

Nếu bạn là một lập trình viên nghiệp dư (không phải lập trình vì tiền), hãy thoải mái lập trình bằng C # hoặc một số ngôn ngữ khác không có ngoại lệ được kiểm tra. Heck, cắt ra người trung gian và chương trình trong Logo. Bạn có thể vẽ những họa tiết xinh xắn trên sàn nhà với chú rùa.

Các trường hợp ngoại lệ được kiểm tra nên đã khuyến khích mọi người xử lý các lỗi gần với nguồn đó. Càng ở xa nguồn, càng nhiều chức năng bị chấm dứt ở giữa hoạt động và càng có nhiều khả năng hệ thống đã vào trạng thái không nhất quán. Ngoài ra, nhiều khả năng bạn bắt gặp ngoại lệ sai do tai nạn.

Đáng buồn thay, mọi người có xu hướng bỏ qua các ngoại lệ hoặc thêm thông số kỹ thuật ném ngày càng tăng. Cả hai đều bỏ lỡ điểm của những trường hợp ngoại lệ được kiểm tra là giả sử để khuyến khích. Chúng giống như chuyển đổi mã thủ tục để sử dụng nhiều hàm Getter và Setter được cho là biến nó thành OO.

Về cơ bản, các ngoại lệ được kiểm tra đang cố gắng chứng minh một mức độ chính xác nhất định trong mã của bạn. Ý tưởng của nó khá giống với kiểu gõ tĩnh, ở chỗ nó cố gắng chứng minh rằng một số thứ là chính xác trước khi mã thậm chí chạy. Vấn đề là tất cả những bằng chứng bổ sung đó có cần nỗ lực và nỗ lực đó có đáng không?