2012-02-15 42 views
8

Bạn có nghĩ rằng việc sử dụng mã lỗi trong trường hợp ngoại lệ để chỉ định loại lỗi có được chấp nhận không? Hãy xem trên mã này:Mã lỗi trong trường hợp ngoại lệ so với trường hợp ngoại lệ hierarhy

public class MyException extends Exception { 
    public static final String ERROR_CODE_INVALID_NAME = ""; 
    public static final String ERROR_CODE_INVALID_ID = ""; 
    ... 

    private String errorCode; 

    public MyException(String message, String errorCode) { 
     super(message); 
     this.errorCode = errorCode; 
    } 

    public String getErrorCode() { 
     return errorCode; 
    } 
} 

Tôi biết rằng nó là tốt hơn để sử dụng enum thay vì Strings trong ví dụ này, nhưng tôi thực sự lo ngại về các khái niệm về mã lỗi. Bạn có nghĩ rằng trường hợp ngoại lệ sẽ là tốt hơn ở đây? Tôi không thể tìm thấy bất kỳ nguồn có thẩm quyền nào cho biết mã lỗi trong trường hợp ngoại lệ là chống mẫu. Thx.

+0

Có vẻ giống như một bản sao của http://stackoverflow.com/questions/446663/best-way-to-define-error-codes-strings-in-java. –

+0

Thx, tôi đã thấy câu hỏi này, nhưng không có một cuộc thảo luận rằng cách tiếp cận này nói chung là sai (ngoại trừ một ý kiến ​​cuối cùng). Tôi muốn nâng cao một cuộc thảo luận chính xác theo cách chính xác của cách tiếp cận đó. – Darkoboar

Trả lời

2

Nếu bạn muốn phản ứng khác nhau (trong mã) tùy thuộc vào nguyên nhân gây ra ngoại lệ (tên không hợp lệ hoặc id không hợp lệ) thì tôi khuyên bạn nên có các ngoại lệ khác nhau.

Nếu không, bạn thậm chí không cần phương thức getErrorCode(), bạn chỉ có thể thêm mã lỗi vào thông báo ngoại lệ và ngoại lệ sẽ cung cấp cho bạn tất cả thông tin bạn cần để gỡ lỗi.

8

mã Lỗi này rất hữu ích khi

  • bạn không thể hiển thị một thông báo lỗi đầy đủ (máy giặt món ăn hiển thị)
  • mã phải được xử lý nội bộ (một số logic được kích hoạt nếu một mã nào đó xuất hiện hoặc máy chủ gửi mã lỗi cho ứng dụng khách trong khi khách hàng chịu trách nhiệm về thông báo)
  • chúng tôi có hướng dẫn sử dụng tuyệt vời và người dùng có thể sử dụng mã này để lấy thông tin toàn diện
  • Người dùng không cần biết , nhưng phải liên hệ với nhà cung cấp

Vì vậy, hầu hết thời gian, tôi không thấy bất kỳ giá trị gia tăng nào trong mã lỗi. Tôi thích một hệ thống phân cấp ngoại lệ hoặc ít nhất là thông báo lỗi rõ ràng thực sự hữu ích, khi được tìm thấy trong một logfile (thậm chí 2 năm sau khi lập trình viên đã rời khỏi công ty).

Nếu bạn có yêu cầu đối với mã lỗi - giải pháp không phải là xấu. Cân nhắc việc thu thập tất cả mã lỗi trong một kho lưu trữ trung ương (nộp tài sản) để bạn có thể trao đổi các thiết lập hoàn chỉnh một cách dễ dàng:

myexception.ERROR_CODE_INVALID_NAME=text or number 
myexception.ERROR_CODE_INVALID_ID=text or number 
+0

Là một bổ sung vào danh sách các trường hợp hữu ích: Một số lượng tương đối lớn các trường hợp lỗi tương tự (Trong kịch bản của tôi> 50 điều có thể xảy ra sai trong khi hoạt động mạng di động). Tôi không thấy bất kỳ giá trị nào trong việc cung cấp 50 ngoại lệ khác nhau, nhưng lỗi cụ thể phải bằng cách nào đó được truyền đạt từ mạng đến lớp giao diện người dùng. –

1

Performance-khôn ngoan tạo ra một stacktrace của hệ thống phân cấp ngoại lệ phức tạp là rất tốn kém từ cả hai bộ nhớ và các khía cạnh thời gian, vì vậy nếu bạn tạo một hệ thống phân cấp ngoại lệ tùy chỉnh phức tạp cho thứ gì đó mà bạn có thể giải quyết bằng 3-4 mã lỗi tĩnh ... Tôi thích tùy chọn mã lỗi hơn. Nói chung tôi thích làm việc với các trường hợp ngoại lệ thời gian chạy (không được kiểm tra trong chữ ký phương pháp) cách tiếp cận không hiệu quả của việc bắt ngoại lệ được kiểm tra là ít IMO lỗi thời.

+3

Tạo một ngoại lệ với một mã lỗi không phải là nhanh hơn cũng không ít bộ nhớ chuyên sâu hơn so với việc tạo ra một ngoại lệ có một hệ thống phân cấp siêu lớp lớn. Trong khi gọi hàm tạo có thể mang lại một vài cải tiến nano giây (vì bạn đang gọi ba hàm tạo ít hơn), bạn sẽ cần nhiều bộ nhớ hơn vì bạn cũng đang lưu trữ 'int' (hoặc' enum' hoặc bất kỳ thứ gì). Phần lớn thời gian dành cho việc tạo ra dấu vết ngăn xếp để những gì tôi đang cố gắng nói: tối ưu hóa sớm là gốc rễ của mọi điều ác. Ngoài ra nó chủ yếu là một câu hỏi phong cách. :) – Bombe

+0

@Bombe, đã đồng ý. tạo một stacktrace sẽ là chi phí và không phải là thời gian c'tor. – aviad

2

Tôi thường sử dụng kết hợp cả hai.

Bạn cần phải loại trừ các ngoại lệ của mình và đưa ra quyết định thiết kế.

Ví dụ: bạn có thể sử dụng các thông số như nguồn ngoại lệ, loại, tác động và xử lý để phân loại ngoại lệ của mình. Nếu các ngoại lệ thuộc cùng một danh mục, hãy sử dụng các mã lỗi bên trong. Sử dụng phân cấp cho trường hợp ngoại lệ thuộc các danh mục khác nhau.

Nếu bạn chọn Exception Handling một tham số quan trọng, bạn có thể lựa chọn giữa hai lựa chọn dựa trên cách bạn muốn xử lý chúng:

  1. mã sử dụng lỗi nếu bạn muốn bắt tất cả các loại trong một khối catch và xử lý chúng theo cách tổng quát.
  2. Sử dụng phân cấp nếu bạn muốn bắt loại cụ thể tại một thời điểm và xử lý chúng tương ứng.
3

Từ mã ngoại lệ trải nghiệm của tôi được sử dụng chủ yếu dưới dạng thông báo cho người dùng.

Tôi đã không thấy ngay cả khi ai đó cố gắng phân tích cú pháp thông báo ngoại lệ chung để phản ứng khác nhau tùy thuộc vào mã lỗi, thường được thực hiện thông qua phân cấp ngoại lệ.

Mặt khác, thật khó để tạo lớp con ngoại lệ mới cho từng trường hợp cụ thể và sau đó sử dụng mã ngoại lệ. Ví dụ, nếu đối với mã người dùng nó không đo lường tại sao giao dịch thất bại, nó sẽ khôi phục lại bất kỳ cách nào, nhưng đối với người dùng cuối, điều quan trọng là tại sao nó xảy ra (sai params, kết nối cơ sở dữ liệu hoặc khác). Vì vậy, để tóm tắt, nếu you'r mong đợi các cách khác nhau để xử lý các tình huống khác nhau thì tốt hơn nên sử dụng các loại ngoại lệ khác nhau, nhưng nếu bạn xử lý một số vấn đề theo cùng một cách nhưng chỉ thông báo cho người dùng về nguyên nhân cụ thể thì dễ dàng hơn sử dụng mã ngoại lệ.

Các vấn đề liên quan