Tránh printStackTrace (); sử dụng cuộc gọi ghi nhật ký thay thế


Câu trả lời:


137

Nó có nghĩa là bạn nên sử dụng khung ghi nhật ký như hoặc là và thay vì in trực tiếp các ngoại lệ:

e.printStackTrace();

bạn nên ghi lại chúng bằng cách sử dụng API của khung này:

log.error("Ops!", e);

Khung ghi nhật ký cung cấp cho bạn nhiều sự linh hoạt, ví dụ như bạn có thể chọn xem bạn muốn đăng nhập vào bảng điều khiển hoặc tệp - hoặc có thể bỏ qua một số thông báo nếu bạn thấy chúng không còn phù hợp trong một số môi trường.


39

Nếu bạn gọi printStackTrace()một ngoại lệ, dấu vết được ghi vào System.errđó và rất khó để định tuyến nó ở nơi khác (hoặc lọc nó). Thay vì làm điều này, bạn được khuyến nghị sử dụng khung ghi nhật ký (hoặc một trình bao bọc xung quanh nhiều khung ghi nhật ký, như Apache Commons Logging) và ghi ngoại lệ bằng cách sử dụng khung đó (ví dụ logger.error("some exception message", e)).

Làm điều đó cho phép bạn:

  • ghi câu lệnh nhật ký vào các vị trí khác nhau cùng một lúc, ví dụ: bảng điều khiển và một tệp
  • lọc các báo cáo nhật ký theo mức độ nghiêm trọng (lỗi, cảnh báo, thông tin, gỡ lỗi, v.v.) và nguồn gốc (thường dựa trên gói hoặc lớp)
  • có một số ảnh hưởng đến định dạng nhật ký mà không cần phải thay đổi mã
  • Vân vân.

17

Một chương trình chất lượng sản xuất nên sử dụng một trong nhiều lựa chọn thay thế ghi nhật ký (ví dụ: log4j, logback, java.util.logging) để báo cáo lỗi và các chẩn đoán khác. Điều này có một số lợi thế:

  • Thông báo nhật ký đi đến một vị trí có thể định cấu hình.
  • Người dùng cuối sẽ không nhìn thấy các thông báo trừ khi bạn định cấu hình ghi nhật ký để họ thực hiện.
  • Bạn có thể sử dụng các trình ghi nhật ký và cấp độ ghi nhật ký khác nhau, v.v. để kiểm soát số lượng nhật ký được ghi lại ít hay nhiều.
  • Bạn có thể sử dụng các định dạng appender khác nhau để kiểm soát việc ghi nhật ký trông như thế nào.
  • Bạn có thể dễ dàng cắm đầu ra ghi nhật ký vào một khung ghi nhật ký / giám sát lớn hơn.
  • Tất cả những điều trên có thể được thực hiện mà không cần thay đổi mã của bạn; tức là bằng cách chỉnh sửa tệp cấu hình ghi nhật ký của ứng dụng đã triển khai.

Ngược lại, nếu bạn chỉ sử dụng printStackTrace, người triển khai / người dùng cuối có rất ít quyền kiểm soát và thông báo ghi nhật ký có thể bị mất hoặc hiển thị cho người dùng cuối trong những trường hợp không thích hợp. (Và không có gì khiến người dùng nhút nhát kinh hoàng hơn là một dấu vết ngăn xếp ngẫu nhiên.)


6

Trong Đơn giản, e.printStackTrace () không phải là phương pháp hay vì nó chỉ in ra dấu vết ngăn xếp thành lỗi chuẩn. Vì điều này, bạn không thể thực sự kiểm soát đầu ra này đi đâu.


0

Hầu hết mọi khung ghi nhật ký đều cung cấp một phương thức mà chúng ta có thể chuyển đối tượng có thể ném cùng với một thông báo. Giống:

public trace(Marker marker, String msg, Throwable t);

Họ in stacktrace của đối tượng có thể ném.


Điều này không trả lời câu hỏi.
Stephen C

-1

Hãy nói về khái niệm công ty. Nhật ký cung cấp cho bạn các cấp độ linh hoạt (xem Sự khác biệt giữa logger.info và logger.debug ). Những người khác nhau muốn xem các cấp độ khác nhau, như QAs, nhà phát triển, người kinh doanh. Nhưng e.printStackTrace () sẽ in ra mọi thứ. Ngoài ra, giống như nếu phương thức này sẽ được gọi lại, lỗi tương tự này có thể in nhiều lần. Sau đó, những người của Devops hoặc Tech-Ops trong công ty của bạn có thể phát điên lên vì họ sẽ nhận được những lời nhắc lỗi tương tự. Tôi nghĩ một sự thay thế tốt hơn có thể là log.error("errors happend in XXX", e) Điều này cũng sẽ in ra toàn bộ thông tin dễ đọc hơn e.printStackTrace ()


-3

Lý do chính là Proguard sẽ loại bỏ các cuộc gọi Nhật ký khỏi sản xuất. Bởi vì bằng cách ghi nhật ký hoặc in StackTrace, có thể thấy chúng (thông tin bên trong dấu vết ngăn xếp hoặc Nhật ký) bên trong điện thoại Android bằng ứng dụng Logcat Reader chẳng hạn. Vì vậy, nó là một thực hành xấu cho bảo mật. Ngoài ra, chúng tôi không truy cập chúng trong quá trình sản xuất, tốt hơn nên loại bỏ chúng khỏi sản xuất. Vì ProGuard loại bỏ tất cả các lệnh gọi Nhật ký không phải stackTrace, vì vậy tốt hơn nên sử dụng các khối bắt Đăng nhập và để chúng bị xóa khỏi Sản xuất bởi Proguard.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.