Các lỗi thường gặp trong xử lý ngoại lệ

Một ngoại lệ là sự gián đoạn đối với luồng thực thi thông thường của chương trình Java (hoặc bất kỳ chương trình nào khác). Vi phạm này có thể xảy ra do vi phạm quyền truy cập bộ nhớ, chia cho 0, sự cố khởi tạo, thực thi lệnh không hợp lệ hoặc bất kỳ lỗi nghiêm trọng nào khác. Java có khả năng xử lý tất cả các tình huống không mong muốn như vậy một cách khéo léo, nhưng khi các nhà phát triển sử dụng các tính năng Java này, một số vấn đề có thể phát sinh. Trong bài viết này, tôi sẽ không thảo luận về cách hoạt động của Xử lý ngoại lệ trong Java. Tôi cho rằng người đọc đã quen thuộc với hệ thống phân cấp ngoại lệ, các ngoại lệ được kiểm tra , các ngoại lệ không được kiểm tra và các ngoại lệ trong thời gian chạy . Ở đây chúng ta sẽ thảo luận về những sai lầm phổ biến nhất mà bạn nên tránh.

Các bên liên quan trong trường hợp ngoại lệ

Bất cứ khi nào luồng thực thi bị gián đoạn, thông tin về nó phải được trả về cho người thực thi chương trình. Chuỗi này có thể bắt đầu từ màn hình, từ một tác vụ hàng loạt hoặc theo bất kỳ cách nào khác. Tất cả các trình kích hoạt này chờ đợi một số loại vi phạm trong luồng để truyền thông báo có định dạng nhất định. Trình kích hoạt dựa trên màn hình có thể nhẹ nhàng cho chúng tôi biết rằng có một số vấn đề kỹ thuật và chúng tôi nên liên hệ với bộ phận hỗ trợ để được trợ giúp và tư vấn. Các quy trình hàng loạt hoặc các chương trình Java độc lập có thể mong đợi báo cáo lỗi xuất hiện dưới dạng một loại nhật ký nào đó mà người dùng cuối hoàn toàn không thể hiểu được. Nhưng người kinh doanh cần nhận được tin nhắn bằng ngôn ngữ mà họ hiểu. Ngoại lệ NullPointerException đáng sợ trong tâm trí người dùng rất khó chịu. Đôi khi những lỗi này là hậu quả của việc sử dụng chương trình không đúng cách, nhưng đôi khi chúng là những vấn đề cần được sửa chữa. Bên liên quan quan trọng thứ hai là người sẽ phải giải quyết các vấn đề do ngoại lệ nảy sinh. Người này không thể quan sát việc thực hiện chương trình thực tế khi xảy ra ngoại lệ. Nó sẽ dựa vào hai điều - thứ nhất, thông tin được cung cấp bởi người dùng đang gặp sự cố và thứ hai, một số loại nhật ký được tạo khi xảy ra ngoại lệ. Ngoài ra, người sẽ phân tích vấn đề không phải là người viết chương trình và do đó người phát triển chương trình phải cung cấp đủ thông tin cho việc phân tích. Cách liên lạc duy nhất giữa nhà phát triển chương trình và trình gỡ lỗi của nó là nhật ký. Ngoài ra, đôi khi vì lý do bảo mật, nhật ký nhật ký đôi khi có thể không chứa tất cả chi tiết thực tế về việc thực thi chương trình khi xảy ra ngoại lệ. Hãy xem xét các lỗi có thể xảy ra trong việc xử lý ngoại lệ. Một số người trong số họ trông khá ngu ngốc, nhưng vẫn có người. những người không chú ý đến chúng cho đến khi những lỗi này dẫn đến vấn đề.

Khối ngoại lệ trống

Đây là một trong những lỗi không mong muốn nhất trong xử lý ngoại lệ. Trong trường hợp này, ngoại lệ đơn giản bị bỏ qua. Giải pháp không chứa gì ngoài một dòng bình luận để lại ngoại lệ. try{ }catch(SQLException sqe){ // do nothing } Trong một số trường hợp hiếm hoi, chẳng hạn như trong khối cuối cùng khi cơ sở dữ liệu bị tắt, các ngoại lệ có thể được đưa ra. Trong trường hợp này, chúng có thể được bỏ qua. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Khái quát hóa không chính xác của thông báo ngoại lệ

Điểm này là chủ quan. Sau khi bắt được ngoại lệ, bạn có thể báo cáo nó cho người dùng cuối dưới dạng một tin nhắn thân thiện. Rất có thể các chi tiết của tin nhắn gốc sẽ bị mất khi các tin nhắn gốc được chuyển đổi thành một tin nhắn chung. Thông báo phải truyền tải thông tin phù hợp đến người dùng cuối để khi liên hệ với nhóm hỗ trợ, người dùng chỉ cần đăng nhập vào nhật ký thích hợp để cung cấp thông tin. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Trong ứng dụng nhiều tầng, mỗi lớp sẽ bắt các ngoại lệ và đưa ra một loại ngoại lệ mới. Đôi khi nhất thiết phải loại bỏ một ngoại lệ của một loại nhất định: - Lớp truy cập dữ liệu -> tạo DataAccessException - Lớp triển khai nghiệp vụ -> tạo BusinessException - Lớp dịch vụ ứng dụng -> tạo ApplicationServiceException Mọi thứ có vẻ hợp lý phải không? Ở đây chúng ta có thể phải chọn giữa ApplicationServiceException và BusinessException vì cả hai đều có thể biểu thị cùng một thông tin. Một trong những chuyển đổi ngoại lệ này có vẻ không cần thiết.

Phá hủy lớp StackTrace

Trong quá trình chuyển đổi một ngoại lệ thành một loại đặc biệt mới, dấu vết ngăn xếp có thể biến mất, khiến việc tìm ra nguyên nhân thực sự của ngoại lệ trở thành một cơn ác mộng. Trong đoạn mã bên dưới, bạn có thể thấy cách ném một ngoại lệ mới mà không nhận được bất kỳ thông tin nào từ ngoại lệ ban đầu. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Ghi đè lý do ngoại lệ

Mỗi thông báo ngoại lệ chứa thông tin về lý do ngoại lệ. Tuy nhiên, khi một ngoại lệ mới được tạo ra, thông tin về ngoại lệ cũ có thể bị xóa vĩnh viễn. Điều này tương tự như ví dụ ở trên, trong đó StackTrace có thể bị xóa do một ngoại lệ mới được đưa ra.

Không tìm kiếm ngoại lệ cụ thể

Đôi khi các nhà phát triển muốn chơi an toàn khi xử lý các trường hợp ngoại lệ. Đôi khi điều này rất dễ thực hiện. Nhưng việc bắt java.lang.Exception thay vì một ngoại lệ cụ thể là không thể chấp nhận được. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Bắt và ném không cần thiết

Nắm bắt các ngoại lệ nếu bạn muốn chuyển đổi chúng sang loại khác hoặc nếu điều đó giúp bạn thêm một số thông tin vào thông báo ngoại lệ cho người dùng cuối hoặc nhà phân tích. Nếu không, chỉ cần vứt chúng đi xa hơn trong chữ ký phương thức (sử dụng lần ném) thay vì bắt chúng.

Bắt ngoại lệ thời gian chạy

Tôi khuyên bạn nên tránh bắt RuntimeException. Thay vào đó, tốt hơn là bạn nên nắm bắt những trường hợp ngoại lệ cụ thể và xử lý chúng.

Tìm các ngoại lệ không được kiểm tra

Đó là một chủ đề gây tranh cãi về việc có nên bắt các ngoại lệ không được kiểm tra hay không. NullPointerException và ArrayIndexOutOfBound có thể là ví dụ điển hình nhất về các ngoại lệ không được kiểm tra. Thay vì nắm bắt những ngoại lệ này, bạn có thể thay đổi mã của mình để xử lý các tình huống này. Ví dụ: để tránh NullPointerException, để đảm bảo rằng tất cả các biến được khởi tạo, để tránh các ngoại lệ ArrayIndexOutOfBound, để xác định một mảng có độ dài chính xác, v.v.

Các vấn đề liên quan đến ghi nhật ký ngoại lệ

Tạp chí sẽ giúp ích cho người quan tâm thứ hai, tức là người phân tích vấn đề. Đôi khi nhà phát triển sử dụng quá nhiều tệp nhật ký và nhật ký được tạo ở mọi cấp độ của ứng dụng. Nhật ký sẽ ghi lại ngoại lệ ở cấp độ mà nó xảy ra. Có vẻ tối ưu nhất là hiển thị cảnh báo rằng một ngoại lệ đã xảy ra, cùng với đề xuất dừng hoặc tiếp tục thực hiện chương trình và bắt buộc ghi lại ngoại lệ đó vào nhật ký.

Ngoại lệ kiểm soát luồng

Một ngoại lệ là làm gián đoạn luồng thông thường của chương trình, có nghĩa là bạn cần làm gián đoạn luồng này và thông báo cho người dùng cuối về nó. Nếu chúng ta thêm một lệnh gọi phương thức là một luồng thay thế, nó sẽ dẫn đến những vấn đề bảo trì rất lớn. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Việc sử dụng phổ biến java.lang.Exception

Bạn cũng không nên sử dụng java.lang.Exception ở mọi nơi cho bất kỳ ngoại lệ nào. Thay vào đó, tốt hơn là sử dụng các ngoại lệ dành riêng cho ứng dụng hoặc các ngoại lệ Java tiêu chuẩn thích hợp nhất. Bài viết gốc: Những lỗi thường gặp trong xử lý ngoại lệ. Dịch và lồng tiếng bởi: Ve4niY