Thông báo lỗi chi tiết nên như thế nào?

Question

Tôi đã tự hỏi sự đồng thuận chung về thông báo lỗi là gì. Họ nên chi tiết như thế nào?

Tôi đã thực hiện các dự án có thông báo lỗi khác nhau khi nhập số quá lớn, quá nhỏ, có số thập phân, là chuỗi, v.v. nơi mọi thứ đã sai, nhưng mã xử lý lỗi bắt đầu cạnh tranh với logic kinh doanh thực tế về kích thước và bắt đầu phát triển một số lỗi của riêng nó.

Ở phía bên kia tôi đã làm việc trên một dự án mà bạn muốn nhận được lỗi rất chung chung như

SOẠN FAILED LÝ DO 3

Mà không cần phải nói là gần như hoàn toàn vô dụng như lý do 3 hóa ra có nghĩa là một lỗi liên kết.

Vậy đâu là nền tảng trung gian? Làm cách nào để biết liệu tôi đã thêm đủ thông báo lỗi mô tả chưa? Làm cách nào để biết liệu người dùng có thể hiểu được họ đã đi sai không?

Answer 1

Có hai đối tượng mục tiêu có thể có cho thông báo lỗi, người dùng và nhà phát triển.

Thông thường, người dùng phải có thông báo nhắm mục tiêu người dùng.

o nguyên nhân của vấn đề là gì.
o lý do chương trình không thể giải quyết được sự cố
o những gì người dùng có thể làm để khắc phục sự cố.
o cách báo cáo sự cố.

Nếu sự cố được báo cáo, báo cáo phải bao gồm nhiều thông tin ngữ cảnh chương trình nhất có thể.

tên o mô-đun
o chức năng tên
o số dòng
o biến quan tâm trong khu vực nói chung của vấn đề
o thậm chí có một bãi chứa lõi.

Nhắm mục tiêu đúng đối tượng.

Answer 2

Bạn nên trao đổi những gì đã xảy ra và tùy chọn của người dùng là gì, trong ít nhất có thể. Thông báo lỗi càng dài thì người dùng càng ít đọc nó. Theo cùng một mã thông báo, các thông báo lỗi ngắn là khó hiểu và vô dụng. Có một điểm ngọt về độ dài, và nó khác nhau cho mọi tình huống.

Quá ngắn:

đầu vào không hợp lệ.

Quá dài:

Vui lòng nhập một địa chỉ IP được định dạng một cách chính xác, ví dụ như 192.168.0.1. Địa chỉ IP là số được sử dụng để nhận dạng máy tính của bạn trên mạng.

Chỉ cần phải:

Vui lòng nhập một địa chỉ IP hợp lệ.

Theo như bloat mã có liên quan, nếu thêm một mã nhỏ sẽ ngăn người dùng gọi hỗ trợ hoặc bị thất vọng, thì đó là đầu tư tốt.

Answer 3

Tôi sẽ sai về mặt chi tiết hơn, nhưng tôi nghĩ bạn đã trả lời câu hỏi của riêng bạn. Để tránh các bloat trong mã sau đó cung cấp thông tin hữu ích trong các mã/thông báo lỗi nhưng bạn có thể cung cấp thêm chi tiết trong tài liệu có lẽ hoặc với các tập tin trợ giúp hoặc FAQ.

có quá ít thông tin tệ hơn theo ý kiến ​​của tôi.

Nếu bạn đang sử dụng ngôn ngữ có nội dung phong phú hoặc các khả năng khác, nhật ký với dòng của anh ấy không thể kiểm tra sẽ hữu ích. Sau đó, người dùng có thể chuyển tiếp tới hỗ trợ kỹ thuật hoặc lấy thông tin chi tiết và đây không phải là mã bổ sung, nhưng sử dụng mã của riêng bạn để cung cấp thông tin.

Answer 4

Có hai loại thông báo lỗi: Các loại thông báo lỗi này sẽ được người dùng nhìn thấy và những thông tin mà người lập trình sẽ nhìn thấy.

"Làm cách nào để biết liệu người dùng có thể hiểu được họ đã đi sai không?" Tôi giả định rằng những tin nhắn đó sẽ chỉ được người dùng nhìn thấy và không phải là thông báo kỹ thuật và COMPILE FAILED REASON 3 không phải là thông báo lỗi điển hình của người dùng cuối. Đó là điều mà lập trình viên sẽ thấy (người dùng thường không biên dịch).

Vì vậy, nếu đó là người dùng sẽ nhìn thấy nó:

1. Cung cấp một đoạn ngắn "Đây là một thông báo lỗi" ("Ops Something đã đi sai!", Vv)
2. Cung cấp mô tả chung chung của lỗi ("Trang web bạn đang cố kết nối dường như không khả dụng"/"Bạn dường như không có đủ quyền để thực hiện tác vụ XYZ"/etc.)
3. Thêm "Chi tiết >> nút "" trong trường hợp người dùng của bạn tình cờ hiểu máy tính tốt, bao gồm thông tin chi tiết (theo dõi ngăn xếp ngoại lệ, mã lỗi, v.v.)

Cuối cùng, cung cấp một số lệnh đơn giản và dễ hiểu cho người sử dụng ("Thử lại", "Hủy", vv)

Answer 5

Câu hỏi thực sự về các thông báo lỗi là nếu họ thậm chí sẽ được hiển thị. Rất nhiều thông báo lỗi được trình bày cho người dùng nhưng không có cách nào để họ sửa chúng.

Miễn là có cách sửa lỗi sau đó cung cấp đủ thông tin cho người dùng để cho phép họ tự sửa lỗi. Nếu họ không thể tự sửa chữa nó thì có lý do gì để nói cho họ biết lý do kỹ thuật cho vụ tai nạn không? Không chỉ cần đăng nhập nó vào một tập tin để xử lý sự cố sau này.

Answer 6

Như đã trình bày như họ cần phải được;)

Tôi biết nó có vẻ giống như một câu trả lời ass thông minh nhưng rất nhiều những điều này phụ thuộc vào đối tượng mục tiêu của bạn và loại lỗi. Đối với các lỗi do mục nhập người dùng không hợp lệ, bạn có thể hiển thị cho họ những gì cấu thành một mục nhập hợp lệ. Đối với các lỗi mà người dùng không thể kiểm soát, thông báo chung "chúng tôi đang làm việc trên đó" có thể làm.

Tôi đồng ý với nhận xét của Jon B về độ dài.

Answer 7

Thông báo lỗi phải chi tiết, nhưng rõ ràng. Điều này có thể đạt được bằng cách kết hợp các thông báo lỗi từ nhiều cấp độ:

Failed to save the image 
Permission denied: /foo.jpg 

Ở đây chúng tôi có hai cấp độ. Có thể có nhiều hơn. Đầu tiên chúng tôi nói với bức tranh lớn và sau đó chúng tôi nói với các chi tiết. Thứ tự là như vậy mà đầu tiên chúng tôi có phần hiểu được nhiều nhất và sau đó phần ít người hiểu, nhưng cả hai vẫn có thể được nhìn thấy.

Ngoài ra, có thể có đề xuất sửa lỗi.