2011-12-20 42 views
5

Tôi không hiểu tính năng này của Java. Tôi biết nó làm cho việc viết mã dễ dàng hơn và đôi khi trông gọn gàng hơn, nhưng việc sử dụng thực tế cái này là gì? Ngược lại tôi cảm thấy, nó tốt hơn để hiển thị các cảnh báo, như trong tương lai bất kỳ ai có thể giới thiệu chúng trước khi thực hiện sửa đổi mã. Liệu @SuppressWarnings này có làm tăng hiệu quả khiếu nại HOẶC điều này theo bất kỳ tiêu chuẩn mã hóa nào không?Việc sử dụng @SuppressWarnings

Trả lời

5

câu trả lời khác đã giải thích trường hợp sử dụng của @SuppressWarnings rất nhiều, nhưng tôi muốn nhấn mạnh quan điểm rằng đôi khi bạn hoàn toàn cần phải sử dụng @SuppressWarnings để vượt qua những hạn chế của ngôn ngữ riêng của mình, và trong những trường hợp sử dụng @SuppressWarnings là hoàn toàn hợp pháp .

Trong trường hợp khác, sử dụng @SuppressWarnings có thể được coi là có vấn đề, vì trong những trường hợp này, bạn luôn có thể loại bỏ cảnh báo bằng cách thay đổi mã (mặc dù, rõ ràng là không phải lúc nào cũng chấp nhận được).

Dưới đây là một số trường hợp phổ biến khi bạn hoàn toàn không thể thoát khỏi cảnh báo mà không @SuppressWarnings:

  • Thực hiện một bộ sưu tập chung mảng hậu thuẫn (vì bạn không thể tạo một mảng generic)
  • Một Map từ các lớp học để triển khai của chúng (vì bạn không thể chỉ định các giá trị khác nhau của thông số loại chung cho các bản đồ khác nhau)
1

Việc sử dụng thực tế là để ngăn chặn cảnh báo. Đó là nó. Không có gì ít hơn, không có gì hơn. Tôi không nghĩ rằng nó ảnh hưởng đến bất kỳ hiệu quả biên dịch nhưng chắc chắn không chạy hiệu quả thời gian.

3

Khi bạn đang xử lý mã cũ không hỗ trợ Generics (Java < = 1.4), đó là cách duy nhất có thể thoát khỏi cảnh báo truyền.

+2

'SuppressWarnings' không chỉ được sử dụng cho Generics support or cast warning. –

+1

ai nói họ là :)? –

+0

Đọc lại bài đăng của bạn. –

9

Trong khi lập trình, bạn nên chú ý cảnh báo trình biên dịch và trong trường hợp tốt nhất, hãy biên dịch mã của bạn mà không có cảnh báo (và tất nhiên là lỗi).

Nhưng đôi khi bạn không thể thoát khỏi cảnh báo và bạn BIẾT mã là chính xác hoặc không thể thay đổi. Sau đó, bạn không muốn bị làm phiền mỗi lần từ trình biên dịch rằng có điều gì đó sai trái.

Vì vậy, bạn có thể chặn nó bằng lệnh bạn đã đề cập.

1

Việc sử dụng SuppressWarnings sẽ được sử dụng trong quá trình biên dịch (do đó, chỉ trình biên dịch biết phải làm gì khi thấy chú thích SuppressWarnings).

Các JavaDoc trạng thái:

The set of warnings that are to be suppressed by the compiler in the annotated element. Duplicate names are permitted. The second and successive occurrences of a name are ignored. The presence of unrecognized warning names is not an error: Compilers must ignore any warning names they do not recognize. They are, however, free to emit a warning if an annotation contains an unrecognized warning name.

1

Có nhiều lý do cho việc sử dụng @SuppressWarnings nhưng một trong những trường hợp rất hữu ích nhất là:

  • Có một dự án hiện với hàng ngàn cảnh báo. Bạn muốn nhóm của bạn chăm sóc cảnh báo ngay bây giờ nhưng bạn không có thời gian để sửa tất cả các cảnh báo.

    Chú thích cung cấp cho bạn cơ hội để chặn một số cảnh báo không thể sửa lỗi nhanh và nhận được cơ sở "sạch".

    Cơ sở sạch này là điều cần thiết vì không ai sợ kiểm tra mã với cảnh báo khi có hàng nghìn mã, nhưng họ sẽ sợ khi codebase cảnh báo miễn phí và mọi người khác trong nhóm sẽ thấy ngay khi ai đó kiểm tra mã với 2 cảnh báo hoặc hơn.

  • Bạn đang sử dụng lib của bên thứ 3 và do đó bạn cảm thấy khó chịu với cảnh báo bạn không thể khắc phục ngoại trừ việc thay đổi mã của lib mà bạn không muốn trong hầu hết các trường hợp.

Theo tôi, lý do đầu tiên là một trong những trường hợp sử dụng tốt nhất cho @SuppressWarnings.

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