Tôi đã và đang làm việc trên một ứng dụng Android try/catchthường xuyên sử dụng để ngăn nó gặp sự cố ngay cả ở những nơi không cần thiết. Ví dụ,
Một chế độ xem trong xml layoutvới id = toolbarđược tham chiếu như:
// see new example below, this one is just confusing
// it seems like I am asking about empty try/catch
try {
View view = findViewById(R.id.toolbar);
}
catch(Exception e) {
}
Cách tiếp cận này được sử dụng trong toàn bộ ứng dụng. Dấu vết ngăn xếp không được in và thực sự khó để tìm ra điều gì đã xảy ra. Ứng dụng đóng đột ngột mà không in bất kỳ dấu vết ngăn xếp nào.
Tôi yêu cầu tiền bối giải thích cho tôi và anh ấy nói,
Điều này là để ngăn ngừa sự cố trong quá trình sản xuất.
Tôi hoàn toàn không đồng ý với nó . Đối với tôi, đây không phải là cách để ngăn các ứng dụng bị treo. Nó cho thấy rằng nhà phát triển không biết mình đang làm gì và đang nghi ngờ.
Đây có phải là cách tiếp cận đang được sử dụng trong ngành để ngăn các ứng dụng doanh nghiệp gặp sự cố không?
Nếu try/catchthực sự, thực sự nhu cầu của chúng ta thì liệu có thể đính kèm một trình xử lý ngoại lệ với chuỗi giao diện người dùng hoặc các chuỗi khác và bắt mọi thứ ở đó không? Đó sẽ là một cách tiếp cận tốt hơn nếu có thể.
Đúng, trống try/catchlà không tốt và ngay cả khi chúng tôi in dấu vết ngăn xếp hoặc ngoại lệ nhật ký cho máy chủ, việc gói các khối mã try/catchngẫu nhiên trên tất cả các ứng dụng không có ý nghĩa đối với tôi, ví dụ: khi mọi chức năng được bao bọc trong a try/catch.
CẬP NHẬT
Vì câu hỏi này đã được rất nhiều người chú ý và một số người đã hiểu sai câu hỏi (có lẽ vì tôi chưa diễn đạt rõ ràng) nên tôi sẽ diễn đạt lại nó.
Đây là những gì các nhà phát triển đang làm ở đây
Một chức năng được viết và thử nghiệm , nó có thể là một chức năng nhỏ chỉ khởi tạo các khung nhìn hoặc một chức năng phức tạp, sau khi thử nghiệm, nó được bao bọc xung quanh
try/catchkhối. Ngay cả đối với hàm sẽ không bao giờ ném ra bất kỳ ngoại lệ nào.Thực hành này được sử dụng trong toàn bộ ứng dụng. Đôi khi dấu vết ngăn xếp được in và đôi khi chỉ là một
debug logthông báo lỗi ngẫu nhiên. Thông báo lỗi này khác nhau giữa các nhà phát triển.Với cách tiếp cận này, ứng dụng không bị lỗi nhưng hành vi của ứng dụng trở nên không xác định. Thậm chí đôi khi thật khó để theo dõi những gì đã xảy ra.
Câu hỏi thực sự tôi đã hỏi là; Đó có phải là thông lệ đang được áp dụng trong ngành để ngăn chặn các ứng dụng doanh nghiệp bị treo? và tôi không hỏi về thử / bắt trống . Có phải người dùng yêu thích ứng dụng không bị treo hơn ứng dụng hoạt động bất ngờ không? Bởi vì nó thực sự dẫn đến sự cố hoặc làm cho người dùng thấy màn hình trống hoặc hành vi mà người dùng không biết.
Tôi đang đăng một vài đoạn mã từ mã thực ở đây
private void makeRequestForForgetPassword() { try { HashMap<String, Object> params = new HashMap<>(); String email= CurrentUserData.msisdn; params.put("email", "blabla"); params.put("new_password", password); NetworkProcess networkProcessForgetStep = new NetworkProcess( serviceCallListenerForgotPasswordStep, ForgotPassword.this); networkProcessForgetStep.serviceProcessing(params, Constants.API_FORGOT_PASSWORD); } catch (Exception e) { e.printStackTrace(); } } private void languagePopUpDialog(View view) { try { PopupWindow popupwindow_obj = popupDisplay(); popupwindow_obj.showAsDropDown(view, -50, 0); } catch (Exception e) { e.printStackTrace(); } } void reloadActivity() { try { onCreateProcess(); } catch (Exception e) { } }
Nó không trùng lặp với các phương pháp hay nhất về xử lý ngoại lệ của Android , OP đang cố gắng bắt ngoại lệ cho một mục đích khác với câu hỏi này.
catch(Exception e){}- nhận xét này có ý nghĩa trước khi chỉnh sửa cho câu hỏi