Tại sao nhiều thông báo ngoại lệ không chứa chi tiết hữu ích?

Dường như có một số lượng thỏa thuận nhất định rằng các thông báo ngoại lệ nên chứa các chi tiết hữu ích .

Tại sao nhiều ngoại lệ phổ biến từ các thành phần hệ thống không chứa các chi tiết hữu ích?

Một vài ví dụ:

• NET Listtruy cập chỉ mục ArgumentOutOfRangeExceptionnào không cho tôi biết giá trị chỉ số mà bị xét xử và không hợp lệ, cũng không cho tôi biết phạm vi cho phép.
• Về cơ bản, tất cả các thông báo ngoại lệ từ thư viện chuẩn MSVC C ++ hoàn toàn vô dụng (trong cùng một hướng dẫn như trên).
• Các trường hợp ngoại lệ của Oracle trong .NET, nói với bạn (không hiểu) "Không tìm thấy BẢNG HOẶC XEM", nhưng không tìm thấy cái nào .

Vì vậy, đối với tôi, dường như đối với hầu hết các thông báo ngoại lệ không chứa đủ chi tiết hữu ích. Là kỳ vọng của tôi ngoài dòng? Tôi có đang sử dụng ngoại lệ sai mà tôi thậm chí nhận thấy điều này? Hoặc có lẽ ấn tượng của tôi là sai: đa số trường hợp ngoại lệ làm thực sự cung cấp thông tin chi tiết hữu ích?

Các ngoại lệ không chứa các chi tiết hữu ích vì khái niệm ngoại lệ chưa đủ chín muồi trong kỷ luật công nghệ phần mềm, vì vậy nhiều lập trình viên không hiểu chúng đầy đủ và do đó họ không đối xử đúng với chúng.

Có, IndexOutOfRangeExceptionnên chứa chỉ mục chính xác nằm ngoài phạm vi, cũng như phạm vi hợp lệ tại thời điểm nó bị ném và nó được coi là thay mặt cho những người tạo ra thời gian chạy .NET mà nó không có. Có, table or view not foundngoại lệ của Oracle phải chứa tên của bảng hoặc dạng xem không được tìm thấy, và một lần nữa, thực tế là nó không được coi thường thay cho bất kỳ ai chịu trách nhiệm cho việc này.

Đối với một phần lớn, sự nhầm lẫn bắt nguồn từ ý tưởng ban đầu sai lầm rằng các ngoại lệ nên chứa các thông điệp có thể đọc được của con người, từ đó bắt nguồn từ sự thiếu hiểu biết về các ngoại lệ là gì, vì vậy đó là một vòng luẩn quẩn.

Vì mọi người nghĩ rằng ngoại lệ nên chứa thông điệp có thể đọc được của con người, họ tin rằng bất kỳ thông tin nào được mang theo ngoại lệ cũng nên được định dạng thành tin nhắn có thể đọc được của con người, và sau đó họ cảm thấy buồn chán khi viết tất cả tin nhắn có thể đọc được của con người- xây dựng mã, hoặc họ sợ rằng làm như vậy có thể tiết lộ một lượng thông tin không đáng có cho bất cứ con mắt tò mò nào có thể nhìn thấy tin nhắn. (Các vấn đề bảo mật được đề cập bởi các câu trả lời khác.)

Nhưng sự thật của vấn đề là họ không nên lo lắng về điều đó bởi vì ngoại lệ không nên chứa thông điệp có thể đọc được. Trường hợp ngoại lệ là những điều mà chỉ lập trình viên nên nhìn thấy và / hoặc giải quyết. Nếu có nhu cầu trình bày thông tin thất bại cho người dùng, điều đó phải được thực hiện ở mức rất cao, một cách tinh vi và trong ngôn ngữ của người dùng, mà theo thống kê, không chắc là tiếng Anh.

Vì vậy, đối với chúng tôi, các lập trình viên, "thông điệp" của ngoại lệ là tên lớp của ngoại lệ và bất kỳ thông tin nào khác phù hợp với ngoại lệ nên được sao chép vào các biến thành viên (cuối cùng / chỉ đọc) của đối tượng ngoại lệ. Tốt hơn là, mỗi một chút có thể tưởng tượng được của nó. Bằng cách này, không có thông điệp nào cần (hoặc nên) được tạo ra, và do đó không có con mắt tò mò nào có thể nhìn thấy nó.

Để giải quyết mối quan tâm được thể hiện bởi Thomas Owens trong một bình luận dưới đây:

Vâng, tất nhiên, ở một mức độ nào đó, bạn sẽ tạo một thông điệp tường trình liên quan đến ngoại lệ. Nhưng bạn đã thấy vấn đề với những gì bạn đang nói: một mặt, một thông báo nhật ký ngoại lệ không có dấu vết ngăn xếp là vô ích, nhưng mặt khác, bạn không muốn cho phép người dùng nhìn thấy toàn bộ dấu vết ngăn xếp ngoại lệ. Một lần nữa, vấn đề của chúng tôi ở đây là quan điểm của chúng tôi bị sai lệch bởi các tập quán truyền thống. Theo truyền thống, các tệp nhật ký thường ở dạng văn bản đơn giản, có thể vẫn ổn trong khi kỷ luật của chúng ta còn ở giai đoạn sơ khai, nhưng có lẽ không còn nữa: nếu có vấn đề bảo mật, thì tệp nhật ký phải là nhị phân và / hoặc được mã hóa.

Cho dù là văn bản nhị phân hay văn bản thuần túy, tệp nhật ký nên được coi là một luồng mà ứng dụng tuần tự hóa thông tin gỡ lỗi. Một luồng như vậy sẽ chỉ dành cho mắt lập trình viên và nhiệm vụ tạo thông tin gỡ lỗi cho một ngoại lệ sẽ đơn giản như việc tuần tự hóa ngoại lệ vào luồng nhật ký gỡ lỗi. Bằng cách này, bằng cách nhìn vào nhật ký, bạn có thể thấy tên lớp ngoại lệ, (như tôi đã nêu, là dành cho tất cả các mục đích thực tế "thông điệp",) từng biến thành viên ngoại lệ mô tả mọi thứ phù hợp- và thực tế để bao gồm trong một bản ghi và toàn bộ dấu vết ngăn xếp. Lưu ý cách định dạng của một thông báo ngoại lệ có thể đọc được của con người bị thiếu một cách rõ rệt từ quy trình này.

PS

Một vài suy nghĩ của tôi về chủ đề này có thể được tìm thấy trong câu trả lời này: Làm thế nào để viết một thông điệp ngoại lệ tốt

PPS

Có vẻ như nhiều người đã bị đánh dấu bởi đề xuất của tôi về các tệp nhật ký nhị phân, vì vậy tôi đã sửa đổi câu trả lời một lần nữa để làm rõ hơn rằng những gì tôi đề nghị ở đây không phải là tệp nhật ký nên là nhị phân, mà đó là tệp nhật ký có thể là nhị phân, nếu cần.

Tại sao nhiều ngoại lệ phổ biến từ các thành phần hệ thống không chứa các chi tiết hữu ích?

Theo kinh nghiệm của tôi, có một số lý do mà các ngoại lệ không chứa thông tin hữu ích. Tôi hy vọng rằng những loại lý do này cũng sẽ áp dụng cho các thành phần hệ thống - nhưng tôi không biết chắc chắn.

• Những người tập trung vào bảo mật xem các trường hợp ngoại lệ là một nguồn rò rỉ thông tin ( ví dụ ). Vì hành vi mặc định của các trường hợp ngoại lệ là hiển thị thông tin đó cho người dùng, các lập trình viên đôi khi nhầm lẫn về mặt thận trọng.
• Trong C ++, tôi đã nghe thấy các đối số chống phân bổ bộ nhớ trong các khối bắt (trong đó ít nhất là một số bối cảnh để tạo ra các thông điệp tốt). Sự phân bổ đó khó quản lý và tệ hơn, có thể gây ra ngoại lệ bộ nhớ ở đó - thường làm hỏng ứng dụng của bạn hoặc rò rỉ bộ nhớ. Thật khó để định dạng các ngoại lệ độc đáo mà không phân bổ bộ nhớ và thực tế đó có thể đã di chuyển giữa các ngôn ngữ như các lập trình viên làm.
• Họ không biết. Ý tôi là, có những kịch bản mà mã không có ý tưởng gì đã xảy ra. Nếu mã không biết - nó không thể cho bạn biết.
• Tôi đã làm việc ở những nơi mà các mối quan tâm nội địa hóa ngăn chặn việc đưa các chuỗi tiếng Anh vào hệ thống - ngay cả đối với các trường hợp ngoại lệ chỉ được đọc bởi các nhân viên hỗ trợ nói tiếng Anh.
• Một số nơi, tôi đã thấy các ngoại lệ được sử dụng giống như khẳng định hơn. Họ ở đó để cung cấp một thông điệp rõ ràng, to lớn trong quá trình phát triển rằng một cái gì đó không được thực hiện hoặc một sự thay đổi đã được thực hiện ở một nơi, nhưng không phải ở một nơi khác. Chúng thường đủ độc đáo để một thông điệp tốt sẽ được nhân đôi nỗ lực hoặc đơn giản là khó hiểu.
• Mọi người lười biếng, lập trình viên nhiều hơn hầu hết. Chúng tôi dành ít thời gian hơn cho con đường đặc biệt hơn con đường hạnh phúc, và đây là một tác dụng phụ.

Là kỳ vọng của tôi ra khỏi dòng? Tôi có đang sử dụng Ngoại lệ sai mà tôi thậm chí nhận thấy điều này?

Có sao không Ý tôi là, ngoại lệ nên có thông điệp tốt, nhưng chúng cũng là ngoại lệ . Bạn nên dành thời gian thiết kế mã để tránh các điều kiện đặc biệt hoặc viết mã để xử lý các điều kiện đặc biệt (bỏ qua thông báo), không sử dụng chúng như một loại cơ chế phản hồi tương tác khi mã hóa. Không thể tránh khỏi việc sử dụng chúng cho mục đích gỡ lỗi, nhưng trong hầu hết các tình huống nên được giữ ở mức tối thiểu. Rằng bạn nhận thấy vấn đề này khiến tôi lo ngại rằng bạn không làm tốt công việc ngăn chặn chúng.

Tôi không có quá nhiều kinh nghiệm về C #, hay cụ thể là C ++, nhưng tôi có thể nói với bạn điều này - các ngoại lệ do nhà phát triển viết 9 trên 10 lần hữu ích hơn bất kỳ ngoại lệ chung nào bạn từng thấy, theo giai đoạn.

Lý tưởng là có, một ngoại lệ chung sẽ chỉ cho bạn chính xác lý do tại sao xảy ra lỗi và bạn sẽ có thể khắc phục dễ dàng - nhưng thực tế, trong các ứng dụng lớn có nhiều lớp có thể đưa ra nhiều loại ngoại lệ khác nhau hoặc cùng một loại ngoại lệ, việc viết kết quả đầu ra của bạn để trả về lỗi luôn có giá trị hơn so với việc dựa vào thông báo mặc định.

Đây là cách nó phải như vậy, vì như nhiều người đã chỉ ra, một số ứng dụng không muốn gửi thông báo lỗi mà họ không muốn người dùng nhìn thấy, vì lý do bảo mật hoặc để tránh nhầm lẫn chúng.

Thay vào đó, bạn nên lường trước trong thiết kế của mình những loại lỗi nào có thể được đưa ra trong ứng dụng của bạn (và sẽ luôn có lỗi) và viết các thông báo bắt lỗi giúp bạn xác định vấn đề.

Điều này sẽ không luôn giúp bạn - bởi vì bạn không thể luôn dự đoán được thông báo lỗi nào sẽ hữu ích - nhưng đây là bước đầu tiên để hiểu ứng dụng của bạn tốt hơn trong thời gian dài.

Câu hỏi đặc biệt là tại sao nhiều trường hợp ngoại lệ được ném bởi "các thành phần hệ thống" (còn gọi là các lớp thư viện chuẩn) không chứa các chi tiết hữu ích.

Thật không may, hầu hết các nhà phát triển không viết các thành phần cốt lõi trong các thư viện tiêu chuẩn, cũng như các tài liệu thiết kế chi tiết hoặc cơ sở thiết kế khác nhất thiết phải được công khai. Nói cách khác, chúng ta có thể không bao giờ biết chắc chắn.

Tuy nhiên, có hai điểm chính cần lưu ý là tại sao thông tin ngoại lệ chi tiết có thể không được mong muốn hoặc quan trọng:

1. Một ngoại lệ có thể được sử dụng bằng cách gọi mã theo bất kỳ cách nào: một thư viện tiêu chuẩn không thể đặt các ràng buộc về cách sử dụng ngoại lệ. Cụ thể, nó có thể được hiển thị cho người dùng. Xem xét một chỉ số mảng ngoài giới hạn: điều này có thể cung cấp thông tin hữu ích cho kẻ tấn công. Nhà thiết kế ngôn ngữ không biết ứng dụng sẽ sử dụng ngoại lệ ném như thế nào hoặc thậm chí đó là loại ứng dụng nào (ví dụ: ứng dụng web hoặc máy tính để bàn), vì vậy việc bỏ thông tin có thể an toàn hơn từ góc độ bảo mật.

2. Các ngoại lệ không nên được hiển thị cho người dùng. Thay vào đó, hiển thị thông báo lỗi thân thiện và ghi nhật ký ngoại lệ vào vị trí kẻ tấn công không có quyền truy cập (nếu có). Khi lỗi được xác định, nhà phát triển nên gỡ lỗi thông qua mã, kiểm tra các khung ngăn xếp và đường dẫn logic. Tại thời điểm này, nhà phát triển có nhiều thông tin hơn một ngoại lệ có thể hy vọng sẽ có.

Trước hết, hãy để tôi làm vỡ bong bóng bằng cách nói ngay cả khi thông điệp diag được tải thông tin đưa bạn đến dòng mã chính xác và lệnh phụ trong 4 giây, rất có thể người dùng sẽ không bao giờ viết nó xuống hoặc chuyển nó đến những người hỗ trợ và bạn sẽ được thông báo "Vâng, nó đã nói điều gì đó về vi phạm ... Tôi không biết nó trông phức tạp!"

Tôi đã viết phần mềm và hỗ trợ kết quả của phần mềm khác trong hơn 30 năm nay và cá nhân tôi, chất lượng hiện tại của một thông báo ngoại lệ hầu như không liên quan gì đến bảo mật, bất kể kết quả cuối cùng xảy ra như thế nào phù hợp với mô hình của họ vũ trụ, rất nhiều để làm với thực tế là rất nhiều người trong ngành của chúng tôi ban đầu được tự học, và họ không bao giờ bao gồm các bài học trong truyền thông. Có lẽ nếu chúng ta CUNG CẤP tất cả các lập trình viên mới vào vị trí bảo trì trong một vài năm mà họ phải đối phó với việc tìm ra điều gì sai, họ sẽ hiểu tầm quan trọng của ít nhất là một dạng chính xác nào đó.

Gần đây, trong một ứng dụng đang được xây dựng lại, một quyết định đã được đưa ra rằng các mã trả lại sẽ thuộc một trong ba nhóm:

• 0 đến 9 sẽ thành công thông qua thành công với thông tin bổ sung.
• 10 đến 99 sẽ không phải là lỗi nghiêm trọng (có thể phục hồi) và
• 101 đến 255 sẽ là lỗi nghiêm trọng.

(100 là vì một số lý do bỏ đi)

Trong bất kỳ quy trình công việc cụ thể nào, suy nghĩ của chúng tôi đã được sử dụng lại hoặc mã chung sẽ sử dụng trả về chung (> 199) cho các lỗi nghiêm trọng, khiến chúng tôi có 100 lỗi nghiêm trọng có thể xảy ra đối với luồng công việc. Với dữ liệu khác biệt nhỏ trong tin nhắn, các lỗi như không tìm thấy tệp có thể sử dụng cùng một mã và phân biệt với các tin nhắn.

Khi mã trở lại từ các nhà thầu, bạn sẽ không tin vào sự ngạc nhiên của chúng tôi khi hầu như MỌI THỨ MỘT L ERI B FATNG LRI đã trả lại mã 101.

Tất cả những gì tôi nghĩ rằng câu trả lời cho câu hỏi của bạn là những tin nhắn rất vô nghĩa bởi vì khi được tạo ra ban đầu, chúng là những phần giữ chỗ mà không ai có thể quay lại. Cuối cùng mọi người đã tìm ra cách khắc phục sự cố không phải vì các tin nhắn mà TRANH CHẤP chúng.

Kể từ đó, những người tự dạy đơn giản là không bao giờ có một ví dụ hay về những gì một ngoại lệ nên chứa. Thêm vào đó, nhiều người dùng không đọc tin nhắn, ít cố gắng chuyển nó để hỗ trợ (Tôi đã thấy các thông báo lỗi bị cắt và dán bởi mục đích sử dụng sau đó được xử lý lại trước khi gửi đi với nhận xét sau đó có vẻ như rất nhiều thông tin và tôi không thể muốn tất cả, vì vậy họ đã ngẫu nhiên loại bỏ một loạt thông tin.

Và hãy đối mặt với nó, với quá nhiều (không phải tất cả nhưng quá nhiều) của thế hệ lập trình viên tiếp theo, nếu đó là công việc nhiều hơn và không thêm flash, chỉ là không đáng ...

Lưu ý cuối cùng: Nếu một thông báo lỗi bao gồm mã lỗi / trả về, thì đối với tôi, ở đâu đó trong các mô-đun được thực thi sẽ có một dòng đọc một cái gì đó như "nếu điều kiện trả về mã-giá trị" và điều kiện sẽ cho bạn biết lý do tại sao mã trả về xảy ra. Đây có vẻ là một cách tiếp cận logic đơn giản, nhưng đối với cuộc sống của tôi, chỉ cần TRY để Microsoft cho bạn biết điều gì đã xảy ra khi nâng cấp cửa sổ không thành công trên CODE 80241013 hoặc một số định danh rất độc đáo khác. Hơi buồn phải không?

Mặc dù tôi đồng ý rằng các ngoại lệ nên chứa càng nhiều thông tin càng tốt, hoặc ít nhất là ít chung chung hơn. Trong trường hợp không tìm thấy bảng, tên bảng sẽ là tốt đẹp.

Nhưng bạn biết nhiều hơn về những gì bạn đã cố gắng thực hiện tại địa điểm trong mã nơi bạn nhận được ngoại lệ. Mặc dù bạn thường thực sự không thể làm gì nhiều để khắc phục tình huống khi có sự cố xảy ra trong thư viện ngoài tầm kiểm soát của bạn, bạn có thể thêm thông tin hữu ích hơn nhiều vào tình huống có sự cố xảy ra.

Trong trường hợp không tìm thấy bảng, nó sẽ không giúp bạn nhiều nếu bạn được thông báo rằng bảng không thể tìm thấy được gọi là SINH VIÊN, vì bạn không có bảng như vậy và chuỗi đó không có trong mã của bạn.

Nhưng nếu bạn bắt được ngoại lệ và suy nghĩ lại bằng câu lệnh SQL mà bạn đang cố thực thi, bạn sẽ thấy tốt hơn, vì hóa ra bạn đã cố gắng chèn một bản ghi với trường tên là Robert '); SINH VIÊN BẢNG SINH VIÊN; (Luôn có xkcd!)

Vì vậy, để chống lại các trường hợp ngoại lệ ít thông tin hơn: hãy thử bắt lại với nhiều thông tin cụ thể hơn với những gì bạn đang cố gắng thực hiện.

Tôi có lẽ nên thêm vào, vì đây là câu trả lời nhiều hơn cho lý do tại sao trong câu hỏi, đó là lý do có thể khiến cho các nhà sản xuất thư viện không tập trung vào việc làm cho các thông điệp ngoại lệ trở nên tốt hơn, là họ không biết Tại sao một cái gì đó đã được thử mà thất bại, logic đó là trong mã gọi.

Để đưa ra một câu trả lời hơi khác: Mã vi phạm có thể đã được thực hiện để chỉ định:

• Hàm nhận X và trả về Y
• Nếu X không hợp lệ, ném ngoại lệ Z

Thêm áp lực để cung cấp chính xác cho thông số kỹ thuật (vì sợ bị từ chối trong đánh giá / kiểm tra) trong thời gian tối thiểu và với sự ồn ào tối thiểu, sau đó bạn có công thức cho một ngoại lệ thư viện hoàn toàn tuân thủ và không có ích.

Các ngoại lệ có chi phí cụ thể về ngôn ngữ và triển khai.

Ví dụ, các ngoại lệ C ++ được yêu cầu để hủy tất cả dữ liệu sống giữa việc ném khung cuộc gọi và bắt khung cuộc gọi và điều đó rất tốn kém. Do đó, các lập trình viên không muốn sử dụng ngoại lệ nhiều.

Trong Ocaml, ném ngoại lệ nhanh gần bằng C setjmp(chi phí của nó không phụ thuộc vào số lượng khung cuộc gọi đi qua), vì vậy các nhà phát triển có thể sử dụng nó rất nhiều (ngay cả đối với các trường hợp không đặc biệt, rất phổ biến). Ngược lại, các ngoại lệ C ++ đủ nặng nên bạn có thể sẽ không sử dụng chúng nhiều như bạn sẽ làm trong Ocaml.

Một ví dụ điển hình là một số tìm kiếm hoặc thăm dò đệ quy có thể bị "dừng lại" bên trong một đệ quy khá sâu (ví dụ: tìm một chiếc lá trong cây hoặc hàm thống nhất). Trong một số ngôn ngữ, nhanh hơn (thành ngữ hơn) để truyền điều kiện đó đến mọi người gọi. Trong các ngôn ngữ khác, ném một ngoại lệ là nhanh hơn.

Vì vậy, tùy thuộc vào ngôn ngữ (và thói quen của các nhà phát triển sử dụng nó), một ngoại lệ có thể mang nhiều chi tiết hữu ích hoặc ngược lại được sử dụng như một bước nhảy nhanh không cục bộ và chỉ mang theo dữ liệu rất hữu ích.

Điều gì khiến bạn nghĩ rằng giá trị chỉ mục hoặc phạm vi yêu cầu hoặc tên của bảng là một chi tiết hữu ích, ngoại trừ?

Ngoại lệ không phải là một cơ chế xử lý lỗi; chúng là một cơ chế phục hồi .

Điểm của các trường hợp ngoại lệ là bong bóng đến mức mã có thể xử lý ngoại lệ. Bất cứ nơi nào mức độ đó, hoặc bạn có thông tin cần thiết, hoặc nó không liên quan. Nếu có thông tin bạn cần, nhưng không có quyền truy cập ngay lập tức , bạn không xử lý ngoại lệ ở cấp độ thích hợp.

Một lần tôi có thể nghĩ về nơi thông tin bổ sung có thể hữu ích là ở cấp cao nhất tuyệt đối của ứng dụng của bạn, nơi bạn gặp sự cố và phát ra lỗi kết xuất; nhưng nó không phải là công việc của ngoại lệ để truy cập, biên dịch và lưu trữ thông tin này.

Tôi không nói rằng bạn chỉ có thể đặt "ngoại lệ mới" ở mọi nơi và gọi nó là tốt, có thể viết các ngoại lệ xấu. Nhưng bao gồm thông tin không liên quan là không cần thiết để sử dụng chúng đúng cách.