Vấn đề của nhà phát triển với các thông báo lỗi hữu ích là gì? [đóng cửa]

29

Nó tiếp tục astounds tôi rằng, trong thời đại ngày nay, các sản phẩm đó có nhiều năm sử dụng dưới vành đai của họ, được xây dựng bởi các nhóm của các chuyên gia, vẫn còn cho đến ngày nay - không cung cấp được các thông báo lỗi hữu ích cho người dùng. Trong một số trường hợp, việc bổ sung chỉ một chút thông tin bổ sung có thể giúp người dùng tránh được hàng giờ rắc rối.

Một chương trình tạo ra lỗi, tạo ra nó vì một lý do. Nó có mọi thứ theo ý mình để thông báo cho người dùng nhiều nhất có thể, tại sao một cái gì đó thất bại. Tuy nhiên, dường như việc cung cấp thông tin để hỗ trợ người dùng là ưu tiên thấp. Tôi nghĩ rằng đây là một thất bại lớn.

Một ví dụ là từ SQL Server. Khi bạn thử và khôi phục cơ sở dữ liệu đang sử dụng, nó hoàn toàn không cho phép bạn. SQL Server biết các quy trình và ứng dụng đang truy cập vào nó. Tại sao nó không thể bao gồm thông tin về (các) quá trình đang sử dụng cơ sở dữ liệu? Tôi biết không phải ai cũng vượt qua một Applicatio_Namethuộc tính trên chuỗi kết nối của họ, nhưng ngay cả một gợi ý về máy đang được đề cập cũng có thể hữu ích.

Một ứng cử viên khác, cũng là SQL Server (và myQuery) là string or binary data would be truncatedthông báo lỗi đáng yêu và tương đương. Rất nhiều thời gian, một dấu hiệu đơn giản của câu lệnh SQL đã được tạo và bảng cho biết cột nào là thủ phạm. Điều này không phải lúc nào cũng đúng, và nếu công cụ cơ sở dữ liệu phát hiện ra lỗi, tại sao nó không thể giúp chúng ta tiết kiệm thời gian đó và chỉ cho chúng ta biết đó là cột chết tiệt nào? Trong ví dụ này, bạn có thể lập luận rằng có thể có một điểm nhấn hiệu năng để kiểm tra nó và điều này sẽ cản trở người viết. Tốt thôi, tôi sẽ mua cái đó. Làm thế nào, một khi công cụ cơ sở dữ liệu biết có lỗi, nó sẽ so sánh nhanh sau thực tế, giữa các giá trị sẽ được lưu trữ, so với độ dài cột. Sau đó hiển thị nó cho người dùng.

Bộ điều hợp bảng khủng khiếp của ASP.NET cũng có tội. Các truy vấn có thể được thực thi và người ta có thể nhận được một thông báo lỗi nói rằng một ràng buộc ở đâu đó đang bị vi phạm. Cảm ơn vì điều đó. Thời gian để so sánh mô hình dữ liệu của tôi với cơ sở dữ liệu, bởi vì các nhà phát triển quá lười biếng để cung cấp ngay cả một số hàng hoặc dữ liệu ví dụ. (Đối với bản ghi, tôi không bao giờ sử dụng phương thức truy cập dữ liệu này theo lựa chọn , đó chỉ là một dự án tôi đã kế thừa!).

Bất cứ khi nào tôi ném một ngoại lệ từ mã C # hoặc C ++ của mình, tôi sẽ cung cấp mọi thứ tôi có trong tay cho người dùng. Quyết định đã được đưa ra để ném nó, vì vậy tôi càng cung cấp nhiều thông tin thì càng tốt. Tại sao chức năng của tôi ném một ngoại lệ? Những gì đã được thông qua, và những gì được mong đợi? Tôi chỉ mất một chút thời gian để đặt một cái gì đó có ý nghĩa trong cơ thể của một thông điệp ngoại lệ. Chết tiệt, nó chẳng giúp được gì cho tôi trong khi tôi phát triển, vì tôi biết mã của tôi ném những thứ có ý nghĩa.

Người ta có thể lập luận rằng các thông báo ngoại lệ phức tạp không nên được hiển thị cho người dùng. Trong khi tôi không đồng ý với điều đó, thì đó là một đối số có thể dễ dàng được xoa dịu bằng cách có mức độ chi tiết khác nhau tùy thuộc vào bản dựng của bạn. Ngay cả khi đó, người dùng ASP.NET và SQL Server không phải là người dùng thông thường của bạn và sẽ thích một cái gì đó đầy đủ thông tin chi tiết và có ích vì họ có thể theo dõi vấn đề của họ nhanh hơn.

Tại sao các nhà phát triển nghĩ rằng không sao, trong thời đại ngày nay, để cung cấp lượng thông tin tối thiểu khi xảy ra lỗi?

Đó là năm 2011 chàng trai, đi trên .

design exceptions error-messages

— Nước ép trái cây
nguồn

11

Wow, đó là một cơn thịnh nộ.

— George Marian

3

@George, bạn có thể nói rằng tôi vừa mất một thời gian dài để theo dõi điều gì đó thực sự có thể được giải quyết nhanh hơn với một lỗi thích hợp không? :)

— Nước ép Moo-

4

Tôi đề nghị hít thở sâu, có thể là yoga & thiền. :) (Điều đó nói rằng, tôi biết chính xác cảm giác của bạn.)

— George Marian

2

+1 - "dữ liệu chuỗi hoặc nhị phân sẽ bị cắt ngắn" luôn khiến tôi phát điên!

— k25

22

Mặc dù có rất nhiều ví dụ về các thông báo lỗi xấu đơn giản là không nên, bạn phải ghi nhớ rằng không phải lúc nào cũng có thể cung cấp thông tin bạn muốn xem.

Ngoài ra còn có mối quan tâm về việc tiết lộ quá nhiều thông tin, điều này có thể khiến các nhà phát triển gặp lỗi về mặt thận trọng. (Tôi hứa với bạn rằng chơi chữ không có ý định, nhưng tôi sẽ không xóa nó ngay bây giờ vì tôi đã nhận thấy nó.)

Đôi khi, có một thực tế là một thông báo lỗi phức tạp là vô dụng đối với người dùng cuối. Đối mặt với tình trạng quá tải thông tin không nhất thiết là một cách tiếp cận tốt cho các thông báo lỗi. (Điều đó có thể được lưu tốt nhất để đăng nhập.)

— George Mary
nguồn

+1 Tôi thậm chí không nghĩ về khía cạnh quá tải thông tin.

— Ryan Hayes

Tôi đã giải thích trong bài viết của mình rằng tôi có thể hiểu tại sao một số người cảm thấy rằng sự dài dòng đối với người dùng cuối có thể là vô ích đối với họ. Nhưng bạn đang nói rằng người dùng cuối của API (bộ điều hợp của ASP.NET) hay công cụ cơ sở dữ liệu (SQL-Server) không muốn có lỗi dài dòng? Một cái gì đó sẽ giúp chúng ta tiết kiệm hàng giờ mất thời gian? Nhân tiện, tôi thích chơi chữ :)

— Moo-Juice

1

@George, cũng liên quan đến tình trạng quá tải thông tin và nó hữu ích cho người dùng cuối, một lần nữa tôi có thể thấy một trường hợp không ném dấu vết đầy đủ cho người sử dụng trình xử lý văn bản, vì họ có thời điểm xử lý màu nâu và nghĩ rằng họ đã xóa internet. Tuy nhiên, bạn đã cung cấp một sự thay thế tuyệt vời với thông tin phức tạp trong tệp nhật ký. Tất cả những thông điệp cần làm bây giờ là thêm For further information, see log20111701.txt. Đây sẽ là một bước đi đúng hướng.

— Moo-Juice

2

@moo Cuối cùng, điều tôi đang nói là rất dễ chỉ trích. (Tôi biết, tôi làm điều đó thường xuyên.) Tuy nhiên, tôi cố gắng ghi nhớ rằng không nhất thiết phải dễ dàng cho biết bạn nên bao gồm bao nhiêu thông tin trong một thông báo lỗi. Đã có rất nhiều lần tôi phải quay lại và đưa ra thông tin chi tiết hơn tôi dự đoán ban đầu trong khi gỡ lỗi. Ngoài ra, có rất nhiều lần thông báo lỗi không hữu ích như tôi dự đoán khi tạo nó.

— George Marian

1

@moo Mấu chốt của vấn đề là không phải lúc nào cũng rõ ràng có bao nhiêu thông tin hữu ích. Các ví dụ bạn cung cấp có vẻ khá rõ ràng. Tuy nhiên, không dễ để mở rộng điều đó sang trường hợp chung.

— George Marian

21

Các nhà phát triển không phải là người thích hợp để viết thông báo lỗi.

Họ nhìn thấy ứng dụng từ góc độ sai. Họ cực kỳ nhận thức được những gì đã xảy ra bên trong mã, nhưng thường không tiếp cận phần mềm theo quan điểm cố gắng hoàn thành một cái gì đó. Do đó, thông tin quan trọng đối với nhà phát triển không nhất thiết là thông tin quan trọng đối với người dùng.

— David Thornley
nguồn

+1 Đối với nhiều loại lỗi Khung / API, một phần của vấn đề là nhà phát triển thư viện không thể biết ngữ cảnh. Điều đó nói rằng, OP dường như chủ yếu quan tâm đến "có gì đó không đúng nhưng tôi sẽ không nói cho bạn biết mặc dù tôi biết" các loại thông báo lỗi. Tôi đoán đó là bảo mật, phải không?

— MIA

8

Quan điểm từ thiện:

Nhà phát triển đã làm việc chặt chẽ với mã và đấu tranh để hiểu được ai đó không hiểu biết về họ làm việc với nó. Kết quả là họ nghĩ rằng các thông báo lỗi là tốt, họ chỉ không có một khung tham chiếu tốt để đánh giá chúng.
Thông báo lỗi thông minh thực sự khó làm. Không chỉ viết chúng mà bạn còn phải tìm ra mọi thứ có thể sai, đánh giá khả năng và cung cấp thông tin hữu ích (hầu như chắc chắn thay đổi dựa trên ngữ cảnh) trở lại cho người đọc tin nhắn để cho phép họ sửa nó.
Đối với hầu hết các ứng dụng, thật khó để tạo ra một trường hợp tốt cho thời gian để thực hiện loại điều này cũng như nhà phát triển tiếp theo sẽ thực sự thích vì lỗi không xảy ra thường xuyên. Bên cạnh đó, nếu bạn có thêm thời gian đó, bạn không nên sử dụng nó để ngăn chặn các lỗi thay vì báo cáo về chúng?

Quan điểm không thuận lợi:

Thông báo lỗi và xử lý lỗi là buồn tẻ, có nhiều điều thú vị hơn để làm việc và ông chủ của tôi đang ở trên lưng tôi về điều tiếp theo. Tôi hiểu mã này, tôi sẽ ổn thôi, anh chàng tiếp theo sẽ giải quyết nó và cuối cùng tôi sẽ ra khỏi đây để không phải là vấn đề của tôi.

Thực tế có lẽ ở đâu đó ở giữa, mặc dù kinh nghiệm của tôi thực sự cho tôi biết nó trước đây hơn nhiều so với sau này - về cơ bản nó thực sự khá khó khăn và phải nỗ lực rất nhiều để đối phó với điều gì đó có lẽ sẽ không xảy ra.

— Jon Hopkins
nguồn

Tôi hiểu bạn đến từ đâu trong nhiều trường hợp người dùng cuối. Tuy nhiên, các trường hợp tôi nêu trong bài viết gốc của mình có thể xảy ra thường xuyên trong khi viết mã chống lại cơ sở dữ liệu. Liên quan đến các ứng dụng của người dùng cuối như trình xử lý văn bản hoặc trò chơi trên máy tính, các lỗi thường không xảy ra trừ khi có điều gì đó xấu xảy ra và thậm chí sau đó lỗi có thể không có ý nghĩa gì với người dùng cuối ( Process Handle Raped By Spawned Injector, Quitting SYstem..... người dùng: "Tôi đã làm gì?"). Nhưng trong trường hợp SQL Server / ASP.NET, tôi nghĩ rằng có thể đã có nhiều nỗ lực hơn :)

— Moo-Juice

@ Moo-Juice - Tôi nghĩ rằng điều đó dẫn đến toàn bộ điều "thông báo lỗi là khó". Dưới vỏ bọc, những gì thực sự được ném vào cơ sở dữ liệu một khi trình tối ưu hóa đã hoàn thành, nó chỉ giống với những gì bạn đã ném vào nó. Xác định lỗi là một chuyện, truy tìm lại những gì đã xảy ra với những gì bạn đã vượt qua nó là một điều hoàn toàn khác và hoàn toàn không tầm thường.

— Jon Hopkins

một số trường hợp có thể không tầm thường. Tôi có một đoạn mã đơn giản ở đâu đó bắt string/binary datalỗi, lấy tất cả thông tin cột từ bảng đã nói, kiểm tra các giá trị trong quá khứ và hiển thị các cột nào sẽ bị vi phạm. Điều này là tầm thường. Có thể tôi đang chê bai quá nhiều vì các ví dụ trường hợp của tôi là tầm thường, nhưng tôi hoàn toàn hiểu rằng điều này không phải lúc nào cũng đúng. Làm thế nào chúng ta ngăn chặn những người tiêm chích sinh sản từ quá trình hãm hiếp có thể khó khăn :)

— Moo-Juice

6

Thật không may, các thông báo lỗi hữu ích hơn làm mất thời gian của nhà phát triển, bằng với tiền của công ty. Sản phẩm đủ đắt để xây dựng như nó là. Vâng, thật tuyệt vời khi có nhiều thông báo lỗi hữu ích hơn và tôi đồng ý rằng sẽ có nhiều thông báo hữu ích hơn. Tuy nhiên, đó chỉ là một thực tế của cuộc sống khi bạn ở dưới thời hạn và tiền đang ở trên đường, bạn phải cắt giảm một số thứ. "Thông báo lỗi đẹp hơn" như các nhà quản lý có thể thấy nó, có thể sẽ là điều đầu tiên xảy ra.

— Ryan Hayes
nguồn

Ah, vâng, điểm tốt. Đó là mối quan tâm hiện tại của chi phí.

— George Marian

Tôi có thể thừa nhận một viễn cảnh chi phí (và chết tiệt, điều đó không có nghĩa là tôi phải thích nó). Tôi không thể nói chuyện từ quan điểm của các nhà phát triển của SQL Server hoặc ASP.NET, nhưng tôi biết rằng nó không mất mà nhiều thêm nỗ lực để cung cấp một tên cột. Tôi thừa nhận rằng, với ví dụ đơn giản của tôi, nó có thể được giải quyết trong một giờ. Sau đó, có 1000 lỗi khác có thể được tạo ra. Nhưng ít nhất họ có thể bắt đầu với những cái chung :)

— Moo-Juice

tất nhiên tôi không biết các phần bên trong của máy chủ SQL - nhưng nói chung, thường xuyên hơn là bạn không có những thông tin đó trong tay tại thời điểm phát hiện ra tình huống lỗi. Một công thức như "dữ liệu chuỗi hoặc nhị phân" cho bạn thấy rõ rằng tại trang web lỗi, thậm chí không rõ giá trị bị cắt là một chuỗi hay một số ...

— Ichthyo

Ở một mức độ nào đó, điều này có thể hợp lệ, nhưng vấn đề tương tự thậm chí còn xuất hiện trong các tập lệnh perl đơn giản khi chỉ cần thêm $! thông báo lỗi sẽ rất hữu ích. Nó rẻ hơn (về thời gian của nhà phát triển) để viết 'die "$ path: $!"' So với việc viết 'die "hoàn toàn vô dụng' die" Không thể mở $ path "'

— William Pursell

6

Tôi đồng ý rằng các thông báo lỗi nên càng cụ thể càng tốt.

Một lý do cho các thông báo lỗi chung có lẽ là việc sử dụng mã lỗi. Khi sử dụng ngoại lệ, bạn có thể tự do vượt qua tất cả những gì bạn cần trong thông báo lỗi. Sử dụng mã trả về không có chỗ để mã hóa tên cột. Có lẽ lỗi được xử lý bởi một hàm chung không biết ngữ cảnh và chỉ đơn giản là dịch mã lỗi thành một chuỗi.

— Thomas
nguồn

thậm chí còn tệ hơn: trong khi bạn có thể kích hoạt lỗi tại các điểm rất cụ thể, để xử lý các lỗi bạn buộc phải đưa một số khả năng vào một lớp tình huống và xử lý chúng với một lần khôi phục. Hành động khái quát hóa này thường xuyên buộc bạn phải loại bỏ thêm thông tin bối cảnh bổ sung khan hiếm.

— Ichthyo

btw ... cơ chế này dẫn đến cả một nhóm thông báo lỗi vui nhộn - dọc theo dòng "Lỗi nghiêm trọng -567 trong Mô-đun lùn678: Không phát hiện thấy lỗi"

— Ichthyo

4

Đôi khi quá nhiều thông tin có thể là một rủi ro bảo mật; bạn không biết ai đang đọc thông báo lỗi
Đôi khi, thao tác ném ngoại lệ phức tạp đến mức không thể có được một thông điệp có ý nghĩa mà không ảnh hưởng tiêu cực đến tốc độ / độ phức tạp của mã

— Người dùng choáng váng
nguồn

Tôi đã trả lời điểm đầu tiên của bạn cho phép thay đổi mức độ chi tiết đối với các ngoại lệ được ném trong mã của bạn. Điểm thứ hai của bạn là phải đưa ra rằng tại thời điểm này, đã xảy ra lỗi và tốc độ không còn là yếu tố quyết định (imho). Và nếu việc tạo ra một thông báo lỗi dài dòng đòi hỏi PRIOR tác động đến hiệu suất để ném ngoại lệ thì tôi đồng ý. Di chuyển mã đó đến SAU ngoại lệ đã được ném. Tôi không thấy một trong những điểm này là một đối số hợp lệ chống lại các thông báo lỗi thích hợp :)

— Moo-Juice

Đúng, tôi cho rằng bạn có thể tìm kiếm thông tin một khi có chuyện gì đó xảy ra thay vì theo dõi những gì bạn có thể cần. Mặc dù, nếu bạn đang ở trong các vòng lặp lồng nhau, việc nắm bắt các chỉ mục / chỉ số có thể có vấn đề.

— Người sử dụng Stuper

-1 cho điểm đầu tiên mà tôi không đồng ý, +1 cho điểm thứ hai.

— Jon Hopkins

1

@jon Tương phản một thông báo lỗi chung cho các lỗi đăng nhập so với các thông báo lỗi cụ thể hơn thực sự cho bạn biết những gì đã sai. ví dụ: "Chúng tôi không thể tìm thấy kết hợp tên người dùng / mật khẩu" so với "Bạn đã nhập mật khẩu không chính xác." / "Tên người dùng đó không tồn tại." Tôi dường như nhớ lại một lỗ hổng trong ASP.NET nơi thông báo lỗi thực sự hữu ích trong việc bẻ khóa các khóa mã hóa.

— George Marian

@George - Tôi đồng ý với ví dụ đó nhưng tôi không nghĩ nó phổ biến. Khi bạn đã được cấp quyền truy cập vào một ứng dụng, một mức độ rủi ro nhất định sẽ biến mất vì bạn có thể cho rằng người đó được (a) ủy quyền và (b) có thể nhận được hầu hết những gì cần thiết từ ứng dụng thực tế.

— Jon Hopkins

3

Như một thông báo chung, bạn nên xem xét rằng bất kỳ lỗi hoặc tình huống đặc biệt nào - chính xác là: ngoại lệ. Nó cắt ngang thủ tục theo kế hoạch và thiết kế. Nó không tương thích với cách mọi thứ được lên kế hoạch để làm việc. Nếu đây không phải là trường hợp, thì sẽ không cần phải bảo lãnh với việc hủy bỏ lỗi.

Chúng tôi lập trình viên được đào tạo để chăm sóc cho việc tự bảo vệ thủ tục theo kế hoạch này. Vì vậy, chúng tôi thường xuyên bao gồm một số kiểm tra độ tỉnh táo để xác minh các giả định của chúng tôi. Khi những kiểm tra về sự tỉnh táo này thất bại, chúng tôi chỉ biết rằng kế hoạch bằng cách nào đó đã thất bại ...

Nhu cầu của bạn - nó có thể trông giống như lẽ thường từ quan điểm của người dùng - là không thể đáp ứng, nếu bạn xem xét thực tế về cách thức hoạt động của một hệ thống như vậy. Bạn yêu cầu một tuyên bố có trật tự với thông tin được tổ chức tốt và phù hợp được thêm vào. Hơn nữa, bạn thậm chí yêu cầu bản trình bày này diễn ra theo cách phù hợp với thiết kế ứng dụng / xử lý chung. Rõ ràng thông tin này tồn tại ở đâu đó trong hệ thống. Rõ ràng nó thậm chí còn tồn tại ở đó một cách có trật tự và được tổ chức tốt (hãy hy vọng như vậy). NHƯNG tại thời điểm xảy ra lỗi, không ai có kế hoạch cung cấp thông tin này. Một lỗi luôn luôn là mất một phần kiểm soát.Sự mất kiểm soát này có thể xảy ra ở các cấp độ khác nhau. Nó có thể là hệ thống hành xử trong thời gian chạy khác với kế hoạch. Nhưng nó cũng có thể là việc thực hiện thực tế trở nên khó khăn và khác biệt hơn nhiều trong các chi tiết sau đó được lên kế hoạch, và không có điều khoản nào được đưa ra để xử lý tình huống này thỏa đáng. Điều này cũng là một mất kiểm soát một phần.

Để liên hệ điều này với ví dụ cụ thể mà bạn đã đưa ra: Nếu, tại thời điểm xảy ra lỗi, tên và loại cột của bảng sẽ được biết và ngoài độ dài của không gian cần thiết, thì sẽ không có lý do nào cho nêu ra một lỗi, phải không? Chúng tôi chỉ có thể khắc phục tình hình và tiến hành theo kế hoạch. Thực tế là chúng tôi buộc phải đưa ra một lỗi cho chúng tôi thấy rằng vấn đề đã đi lệch hướng. Thực tế là những thông tin này không có trong tay là ngoại lệ .

Những gì tôi đang viết ở đây có vẻ như hiển nhiên và chỉ là lẽ thường. Nhưng trong thực tế nó cực kỳ khó nắm bắt. Chúng tôi liên tục cố gắng hiểu nó bằng cách áp dụng các phạm trù đạo đức - như phải có thủ phạm, phải có một người lười biếng không quan tâm đến người dùng nghèo, phải có một doanh nhân tham lam làm cách tính toán rẻ tiền. Tất cả điều này là hoàn toàn bên cạnh điểm

Khả năng mất kiểm soát bắt nguồn từ thực tế là chúng ta đang làm mọi thứ một cách có kế hoạch và có trật tự .

— Ichthyo
nguồn

Tôi phải không đồng ý. Nó biết có gì đó không đúng (không thể thực hiện thao tác). Để biết rằng một cái gì đó sai chỉ ra một kiến thức về lý do tại sao nó sai. Chuỗi này là lớn cho cột đó (hoặc một cột trong bảng đó). Nó có thể cho tôi biết, mà không cần làm việc nhiều. Đó là một công cụ cơ sở dữ liệu doanh nghiệp chết tiệt. Nó biết . Nhưng nó không chuyển tiếp thông tin đó. Cho rằng lập trình viên có thể viết một truy vấn để chạy sau khi thực tế tìm ra cho thấy công cụ cơ sở dữ liệu có thể làm tương tự. Đây không phải là bí mật không có giấy tờ. Chỉ là một thông báo lỗi nhảm nhí :)

— Moo-Juice

heh ... bạn nên dựa trên lập luận của bạn dựa trên logic, chứ không phải dựa trên suy nghĩ trắng trợn. Từ khi nào một máy tính biết bất cứ điều gì? Đây không phải là điện ảnh Hollywood. Chương trình là một thiết lập cứng nhắc, được sắp xếp trước và khi các giả định của bạn bị hỏng, bạn đã mất kiểm soát. Đây thực sự là rất khó để nắm bắt? Một máy tính không hiểu chương trình, và vì vậy anh ta không thể hiểu khi nó bị lỗi. Hầu như không bao giờ, khi một số kích hoạt kiểm tra tính nhất quán, việc thực thi đã được tiến hành bởi hàng ngàn câu lệnh và không ai biết dữ liệu nào đã bị hỏng. Tất cả những gì bạn có thể làm là hạn chế thiệt hại

— Ichthyo

2

Tôi làm việc như một kỹ sư hỗ trợ cho một công ty phần mềm và chúng tôi thường thấy các thông báo lỗi mới đối với chúng tôi. Thường xuyên khi tôi giới thiệu những điều này trở lại nhóm phát triển của chúng tôi, họ phải tìm kiếm thông điệp trong nguồn của ứng dụng.

Dường như với tôi rằng ngay cả khi nó không được trình bày cho người dùng, chúng tôi sẽ an toàn rất nhiều thời gian nếu nhóm nhà phát triển sẽ thêm ghi chú vào tài liệu hoặc cơ sở dữ liệu chỉ mục thông báo lỗi bất cứ khi nào họ thêm nó. chúng tôi nhanh chóng tìm ra nguyên nhân của các vấn đề của khách hàng và tiết kiệm thời gian cho họ ...

— glenatron
nguồn

1

xin lỗi, điều đó khá không thực tế Ai sẽ chịu trách nhiệm quản lý tài liệu chỉ mục đó, để giữ cho nó chính xác. Vì bất kỳ tài liệu bằng văn bản nào tách rời mã, nó sẽ bị lỗi thời và bắt đầu nhận được nguồn cho các lỗi mới ngay khi nó được viết.

— Ichthyo

Ngược lại, đó là loại kịch bản có thể trích xuất từ mã nguồn, nếu mỗi lỗi có một số duy nhất và mô tả của từng mã cũng ở dạng mã dưới dạng nhận xét (được định dạng đặc biệt) hoặc dưới dạng chuỗi. Vì vậy, tài liệu sẽ được tạo tự động với mỗi bản dựng. Thông điệp được trích xuất sau đó có thể chi tiết hơn một chút so với bất cứ điều gì bạn muốn người dùng cuối nhìn thấy. Một ý tưởng không tồi!

— Jeanne Pindar

bạn không cần một tập lệnh cho điều đó - nhiều hệ thống thời gian chạy có thể ghi lại số dòng hoặc một số thông tin tương tự. Thật không may, điều này không giúp ích gì cho vấn đề ban đầu, vì theo cách này chúng ta chỉ biết nơi phát hiện một ngoại lệ nhưng chúng ta không biết điều gì đã xảy ra . Tìm ra cái sau được gọi là gỡ lỗi - trong thực tế, đây là một nhiệm vụ ít nhiều tẻ nhạt và công việc được thực hiện bởi con người.

— Ichthyo

Tôi với @Jeanne - đủ đơn giản để kết hợp mã hoặc để có một chỉ mục trung tâm trong mã với mã lỗi và giải thích chúng. Một khi biết nơi phát hiện một ngoại lệ có thể đủ để cho bạn biết rằng có một vấn đề với môi trường ở đâu đó chứ không phải là một cái gì đó trong mã cần đuổi theo.

— glenatron

2

Vấn đề bạn đang thấy thực sự là một trong những tác dụng phụ của việc đóng gói thông tin và che giấu thông tin thích hợp.

Hệ thống hiện đại vô cùng phức tạp. Có rất ít khả năng nhà phát triển trung bình có thể nắm giữ, trong đầu anh ta, một mô hình tinh thần của toàn bộ hệ thống từ UI đến nhị phân thô trong khi anh ta đang mã hóa bất kỳ nhiệm vụ cụ thể nào.

Vì vậy, trong khi một nhà phát triển đang ngồi xuống và mã hóa, giả sử, bit khôi phục tệp cơ sở dữ liệu, mô hình tinh thần của anh ta được lấp đầy hoàn toàn với các bit xung quanh hành động khôi phục tệp cơ sở dữ liệu. Anh ta cần (và tôi đoán, tôi chưa viết mã này) đọc tệp, kiểm tra thuộc tính, đọc phiên bản, sao lưu dữ liệu hiện có, chọn chiến lược hợp nhất / ghi đè, v.v ... Rất có thể, nếu thậm chí có một lần vượt qua xem xét đến UI, nó nằm trong chuỗi lỗi mà anh ta viết trong một trình xử lý ngoại lệ. Cái gì đó như:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

Trong ví dụ này, thông tin hữu ích mà bạn đang hỏi về các quy trình có thể đang sử dụng tệp hoặc thậm chí các luồng khác trong DB, hoàn toàn nằm ngoài phạm vi (theo chương trình). Có thể có hàng trăm lớp xử lý các tệp DB; nhập vào các lớp đó thông tin về mọi quy trình khác bằng cách sử dụng các tệp hoặc chức năng để truy cập hệ thống tệp và xem xét các quy trình khác đang chạy (giả sử các quy trình đó thậm chí trên máy NÀY) sẽ dẫn đến cái gọi là trừu tượng bị rò rỉ ; có một chi phí trực tiếp trong năng suất.

Vì vậy, đó là cách những loại lỗi này có thể tồn tại trong thời hiện đại. Rõ ràng, tất cả chúng đều được cố định; nhưng trong nhiều trường hợp, có rất nhiều chi phí liên quan hơn người ta nghĩ (ví dụ trong trường hợp này, bạn có thể phải có chức năng này thông qua việc liệt kê các kết nối mạng và chia sẻ để xem liệu một máy từ xa có sử dụng tệp cơ sở dữ liệu này không lý do) và chi phí là xa tầm thường.

— GWLlosa
nguồn

@GWLlosa, đây là một câu trả lời tuyệt vời và tôi chưa xem xét. Điều đó đã nói (và tôi không thể cung cấp một ví dụ mã đầy đủ ở đây), khi tôi nhận được IOException đó, trước khi tôi ném GenericException, tôi có thể 1) Hỏi ProcessesHệ thống con để biết danh sách các quy trình. 2) Hỏi từng quy trình cơ sở dữ liệu họ đang sử dụng. 3) Kết hợp quy trình với cơ sở dữ liệu được gán cho cơ sở dữ liệu tôi đang ghi đè, 4) đưa ra một DatabaseInUse(dbName, processName, applicationNamengoại lệ. :)

— Nước ép Moo-

1

Chắc chắn là có thể; nhưng mã để khớp DB với quy trình (đặc biệt là qua mạng) có thể tự phức tạp / chậm / lỗi, điều này có thể dẫn đến một số thất vọng bổ sung ("Tôi chỉ đang cố gắng khôi phục cục bộ (* #% ^! % file !!!! TẠI SAO TÔI CHĂM SÓC MÀ CHIA SẺ MẠNG KHÔNG CÓ TIẾP CẬN! ??!?! ")

— GWLlosa

1

@ Moo-Juice: những gì bạn đề xuất nghe có vẻ khá ngây thơ. Trong một môi trường đa luồng lớn như cơ sở dữ liệu, bạn không thể liên hệ với một số dịch vụ toàn cầu để có danh sách "tất cả xyz". Ngay cả để nói chuyện với một số dịch vụ khác trong một luồng khác, bạn cần khóa, điều này có thể dẫn đến sự bế tắc của toàn bộ hệ thống, nó có thể làm hỏng dữ liệu khác hoặc ít nhất là nó có thể gây ra lỗi bổ sung, sau đó bạn cũng cần xử lý ....

— Ichthyo

1

Ví dụ mà thực sự là rất bài học: Thông thường trong xử lý một nắm bắt như vậy, bạn thậm chí không thể nói chắc chắn đó là một phần trong khối try thất bại (thường có nhiều bộ phận mà có thể gây ra một IOException). Ngoài ra, rất có thể tại vị trí đó bạn không thể nói tên của tệp, vì sợ bạn có thể biết bảng logic nào tương ứng với tệp này.

— Ichthyo

@Ichthyo, không xúc phạm nhưng tôi không nghĩ nó ngây thơ chút nào. Tôi không yêu cầu công cụ cơ sở dữ liệu khóa hệ thống để cho tôi biết quy trình nào vẫn xử lý cơ sở dữ liệu. Tôi không yêu cầu nó dừng toàn bộ doanh nghiệp. Nếu nó cần cho tôi một câu trả lời đơn giản, điều đó cho thấy lỗ hổng thiết kế cơ bản của máy chủ cơ sở dữ liệu ngay từ đầu. Hãy nhớ rằng, nó được cho là được thiết kế để cung cấp thông tin thích hợp trở lại theo cách nhanh nhất có thể. Để hỏi nó câu hỏi "ai?" thực sự không nên ngây thơ như bạn tuyên bố :)

— Moo-Juice

2

Yêu thích của tôi là (trở lại vào cuối những năm 70), trình biên dịch Univac Fortran IV, khi đọc không phải chữ số, đã công bố một cách trung thực

Việc giải thích dữ liệu vô nghĩa đã được cố gắng

— người cười
nguồn

+1, hoàn toàn tuyệt vời! Đó là loại lỗi khiến bạn chỉ muốn bỏ cuộc và đi nuôi gà ở Fiji.

— Moo-Juice

thật vậy, thông báo lỗi này chính xác 100% - nếu bạn muốn một thông điệp thân thiện hơn với nhiều conetxt hơn, bạn cần xây dựng một số phỏng đoán và phỏng đoán; bằng cách này, bạn thêm khả năng thông báo lỗi gây hiểu lầm ..

— Ichthyo

0

Tôi tin rằng phần lớn các thông báo lỗi thực sự là các câu lệnh code / printf được định hướng lập trình viên tự định hướng.

Viết thông báo lỗi hướng người dùng có nghĩa là biết người dùng của bạn là ai và dự đoán những gì họ sẽ muốn biết. Mặc dù ở giữa mã viết, nhà phát triển có xu hướng viết một thông báo lỗi hữu ích cho chính họ, để gỡ lỗi mã họ đang viết vào lúc này hoặc hữu ích cho (các) Trường hợp sử dụng đã biết hoặc chiếm ưu thế.

Chuyển từ viết mã sang thiết kế một phần văn bản của giao diện người dùng (hoặc trải nghiệm người dùng) là một chuyển đổi ngữ cảnh. Trong các ứng dụng lớn, chẳng hạn như các ứng dụng đa ngôn ngữ có thể có nghĩa là nó được trao cho một người hoặc nhóm khác (UI, dịch) thay vì xử lý hoàn toàn bởi nhà phát triển, vì vậy trừ khi nhà phát triển giải thích cẩn thận ngữ cảnh của thông báo, các chi tiết quan trọng có thể được dễ bị mất

Tất nhiên, kiểm tra và xác minh xử lý lỗi thường được coi là ưu tiên thấp, miễn là các lỗi & ngoại lệ được xử lý (nghĩa là bị bắt), không có nhiều sự nhấn mạnh được dành cho nó. Đó là một vị trí không thể tin được của codebase để các nhà phát triển hoặc QA đánh giá, vì các điều kiện lỗi thường có ý nghĩa tiêu cực (nghĩa là sai lầm hoặc thất bại) liên quan đến chúng.

— mctylr
nguồn

0

Tôi nghĩ lý do là việc báo cáo / xử lý lỗi luôn được thực hiện như sau khi nghĩ . Ngay cả khi họ không hoàn toàn suy nghĩ, họ hầu hết là công dân hạng hai trong thiết kế tổng thể.

Phần mềm hiện đại thường bao gồm nhiều lớp. Khi logic báo cáo lỗi của bạn được đặt ra một cách vội vàng mà không cần suy nghĩ quá nhiều, thường rất khó để thu thập tất cả thông tin cần thiết để trình bày các thông báo lỗi hữu ích.

Ví dụ, lỗi được bắt gặp ở back-end, nhưng nó cần một số thông tin từ các lớp cao hơn để soạn một thông báo lỗi toàn diện. Hầu hết các thông báo lỗi tốt cần thông tin từ hầu hết tất cả các lớp (để cung cấp cho chúng tôi cái nhìn toàn diện về những gì đã xảy ra trong hệ thống). Thông báo lỗi lý tưởng sẽ giống như "OK, lần đầu tiên chúng tôi nhận được một chuỗi, sau đó nó được chuyển qua trình phân tích cú pháp mang lại điều gì đó buồn cười, bạn có thể muốn xem ở đó. Dù sao, điều đó đã được truyền xuống ..."

Làm điều đó thường sẽ yêu cầu khớp nối không cần thiết nếu cơ chế báo cáo lỗi không phải là công dân hạng nhất trong giai đoạn thiết kế. Tôi đoán hầu hết mọi người chỉ thấy rằng có quá nhiều việc phải làm cho một cái gì đó trông không ấn tượng (ai thích nói "Thấy không? Chương trình của tôi bị hỏng và thông báo lỗi là hữu ích!").

— kizzx2
nguồn