Máy chủ có nên được khoan dung trong những gì nó chấp nhận và loại bỏ đầu vào bị lỗi một cách im lặng?

Tôi đã có ấn tượng rằng bây giờ mọi người đồng ý câu châm ngôn này là một sai lầm. Nhưng gần đây tôi đã thấy câu trả lời này có một bình luận "hãy khoan dung" được nâng lên tới 137 lần (tính đến hôm nay).

Theo tôi, sự khoan hồng trong những gì trình duyệt chấp nhận là nguyên nhân trực tiếp của sự lộn xộn hoàn toàn mà HTML và một số tiêu chuẩn web khác đã có từ vài năm trước và chỉ gần đây mới bắt đầu kết tinh chính xác khỏi mớ hỗn độn đó. Cách tôi nhìn nhận nó, khoan dung trong những gì bạn chấp nhận sẽ dẫn đến điều này.

Phần thứ hai của câu châm ngôn là "loại bỏ đầu vào bị lỗi một cách im lặng, mà không trả về một thông báo lỗi trừ khi điều này được yêu cầu kỹ thuật" và điều này gây cảm giác khó chịu. Bất kỳ lập trình viên nào đã đập đầu vào tường khi một cái gì đó thất bại âm thầm sẽ biết ý tôi là gì.

Vì vậy, tôi hoàn toàn sai về điều này? Chương trình của tôi có nên khoan dung trong những gì nó chấp nhận và nuốt lỗi không? Hay tôi đang hiểu sai ý nghĩa của điều này?

Câu hỏi ban đầu nói "chương trình", và tôi đưa ra quan điểm của mọi người về điều đó. Nó có thể có ý nghĩa cho các chương trình được khoan dung. Tuy nhiên, điều tôi thực sự muốn nói là API: giao diện tiếp xúc với các chương trình khác , thay vì con người. HTTP là một ví dụ. Giao thức là một giao diện mà chỉ các chương trình khác sử dụng. Mọi người không bao giờ trực tiếp cung cấp các ngày đi vào tiêu đề như "Nếu được sửa đổi-Kể từ".

Vì vậy, câu hỏi đặt ra là: máy chủ có nên thực hiện một tiêu chuẩn hay không và cho phép ngày ở một số định dạng khác, ngoài định dạng mà tiêu chuẩn thực sự yêu cầu? Tôi tin rằng "hãy khoan dung" được cho là áp dụng cho tình huống này, chứ không phải là giao diện của con người.

Nếu máy chủ khoan dung, nó có vẻ như là một sự cải tiến tổng thể, nhưng tôi nghĩ trong thực tế, nó chỉ dẫn đến việc triển khai máy khách mà cuối cùng dựa vào sự khoan hồng và do đó không thể làm việc với một máy chủ khác có thể khoan dung theo những cách hơi khác.

Vì vậy, một máy chủ nên phơi bày một số API có thể được khoan dung hay đó là một ý tưởng rất tồi?

Bây giờ vào xử lý khoan hồng của đầu vào người dùng. Hãy xem xét YouTrack (một phần mềm theo dõi lỗi). Nó sử dụng một ngôn ngữ để nhập văn bản gợi nhớ đến Markdown. Ngoại trừ việc nó "khoan dung". Ví dụ: viết

- foo
- bar
- baz

là không một cách ghi nhận của việc tạo ra một danh sách liệt kê, nhưng nó làm việc. Do đó, cuối cùng nó đã được sử dụng rất nhiều trong suốt chương trình sửa lỗi nội bộ của chúng tôi. Phiên bản tiếp theo xuất hiện và tính năng nhẹ nhàng này bắt đầu hoạt động hơi khác, phá vỡ một loạt các danh sách mà (mis) đã sử dụng tính năng (không) này. Tất nhiên, cách tạo tài liệu để tạo danh sách gạch đầu dòng vẫn hoạt động.

Vì vậy, phần mềm của tôi có nên khoan dung trong những gì người dùng nhập vào không?

Tất nhiên bạn hoàn toàn đúng. Các chương trình không bao giờ nên được khoan hồng vì làm như vậy chỉ phục vụ để che giấu các vấn đề. Các vấn đề cần được làm nổi bật, không được quét dưới tấm thảm. Một thông báo lỗi thông tin là một điều bắt buộc tuyệt đối để một chương trình có ích cho người dùng.

Hầu hết thời gian khi dữ liệu không chính xác / không hợp lệ được cung cấp, nhà cung cấp dữ liệu đó (cho dù đó là người dùng hay đầu ra của một số chương trình khác) có thể không biết nó không hợp lệ. Nuốt lỗi sẽ khiến họ tin rằng nó là (hoặc có thể) hợp lệ, làm tăng sinh dữ liệu không hợp lệ.

Cách duy nhất để các hệ thống tương tác là để sự tương tác đó được xác định đầy đủ và rõ ràng. Một chương trình chấp nhận dữ liệu ngoài đặc tả làm cho dữ liệu đó thực tế được chấp nhận ngay cả khi thông số đó không hợp lệ, điều này không chỉ khiến khả năng tương thích trở nên khó khăn hơn mà còn có nghĩa là nó không còn được xác định chính thức. Chương trình này là tiêu chuẩn thực tế . Do đó, các chương trình khoan hồng không thể phát triển thêm hoặc thay thế bởi vì bạn không thể thực hiện thay đổi nhỏ nhất đối với cách thức hoạt động.

Tôi nghĩ rằng tất cả phụ thuộc vào nhân khẩu học mục tiêu của bạn là ai. Nếu đó là lập trình viên, thì hoàn toàn không. Chương trình của bạn nên thất bại nặng nề và la hét giết người đẫm máu. Tuy nhiên, nếu đối tượng mục tiêu của bạn không phải là lập trình viên, thì chương trình của bạn nên khoan dung, nơi nó có thể xử lý các ngoại lệ một cách duyên dáng, nếu không, thì thầm giết người đẫm máu ngọt ngào.

Như một trường hợp nghiên cứu, hãy sử dụng trình phát NPAPI Flash. Có một phiên bản "phát hành" cho những người không thực sự quan tâm đến 99% lỗi có thể xảy ra, nhưng cũng có phiên bản "gỡ lỗi" có thể được sử dụng để hét lên án mạng đẫm máu khi có sự cố xảy ra. Mỗi hỗ trợ phát nội dung Flash rõ ràng, nhưng được nhắm mục tiêu vào hai nhân khẩu học hoàn toàn khác nhau.

Cuối cùng, tôi nghĩ rằng điều quan trọng là: Người dùng của bạn quan tâm đến điều gì?

Có hai loại "khoan dung": Một là chấp nhận đầu vào không chính xác và cố gắng hiểu ý nghĩa của nó, và loại kia là chấp nhận các loại đầu vào khác nhau.

Nói chung, bạn luôn muốn cái thứ hai khi nó khả thi. Điều đầu tiên là khi bạn chết nhanh và khó khăn. Một ví dụ: Ngày.

Dưới đây là một số ví dụ đầu vào, bao gồm hợp lệ, không hợp lệ và mơ hồ.

• 2011-01-02
• 01/02/2011
• Jan 2, 2011
• 2-Jan-2011
• Green

Chỉ có một đầu vào không hợp lệ ở đây : Green. Thậm chí đừng cố chấp nhận nó như một cuộc hẹn hò. Vì Greenrõ ràng không phải là một cuộc hẹn hò, đây là một trường hợp mà sự thất bại thầm lặng được chấp nhận.

01/02/2011là hợp lệ, nhưng mơ hồ. Bạn không nhất thiết phải biết liệu nó có được nhập vào ngày ở Hoa Kỳ (ngày 2 tháng 1) hay không (ngày 1 tháng 2). Ở đây, tốt nhất là thất bại lớn tiếng và yêu cầu người dùng cho một ngày rõ ràng.

2011-01-02thường được coi là không rõ ràng, do đó, thường đi trước và cho rằng đó là định dạng "YYYY-MM-DD", và chỉ thất bại trong dòng tiếp theo. Tuy nhiên, đó là một chút của một cuộc gọi phán xét khi xử lý đầu vào của người dùng.

Jan 2, 2011và 2-Jan-2011có giá trị và không mơ hồ, chúng nên được chấp nhận. Tuy nhiên, The Second of January of the year 2011là cũng có giá trị và rõ ràng, nhưng đi xa vì lợi ích của khoan dung là quá mức cần thiết. Đi trước và thất bại nó âm thầm, giống như Green.

Nói tóm lại , câu trả lời là "nó phụ thuộc". Hãy xem những gì có thể được nhập vào và đảm bảo bạn sẽ không bao giờ chấp nhận các loại đầu vào mâu thuẫn (như DD/MM/YYYYvs MM/DD/YYYY).

Trong bối cảnh của câu hỏi / nhận xét được liên kết , Đó là một trường hợp 2011-01-02. Đầu vào trông giống như JSON và sẽ xác nhận hợp lệ như JSON ngay cả khi mimetype sai; hãy tiếp tục và cố gắng sử dụng nó ngay cả khi nó không thành công ở một thời điểm nào đó.

Thất bại trong âm thầm là điều tồi tệ nhất bạn có thể làm, bao giờ hết. Bạn đã thử gỡ lỗi một API với sự thất bại thầm lặng? Điều đó là không thể .

Có "Làm hết sức để phục hồi nhưng gửi lỗi chi tiết" và có "Lỗi im lặng".

Dường như với tôi rằng Luật của Postel - "Hãy thận trọng trong những gì bạn làm, hãy tự do trong những gì bạn chấp nhận từ người khác" là những gì đang được thảo luận cho một dịch vụ JSON. Điều này thường được áp dụng cho các dịch vụ web và không phải UI.

Đối với phản hồi người dùng xây dựng UI và chống lại đầu vào của người dùng là quy tắc ngón tay cái chúng tôi sử dụng.

Tôi nghĩ rằng điều này được đề cập tốt trong chương 1, phần 6 của TAOUP. Cụ thể là quy tắc sửa chữa. , trong đó nêu rõ rằng một chương trình nên làm những gì có thể với đầu vào, chuyển dữ liệu chính xác về phía trước và nếu phản hồi đúng là thất bại thì hãy thực hiện càng sớm càng tốt.

Một khái niệm tương tự là lập trình phòng thủ . Bạn không biết bạn sẽ nhận được loại đầu vào nào, nhưng chương trình của bạn phải đủ mạnh để bao quát mọi trường hợp. Điều này có nghĩa là phải được lập trình trong các trường hợp khôi phục cho các sự cố đã biết như đầu vào bị sai lệch và bắt tất cả các trường hợp để xử lý các ẩn số.

Vì vậy, loại bỏ đầu vào bị lỗi âm thầm là tốt, miễn là bạn đang xử lý đầu vào đó. Bạn không bao giờ nên thả nó xuống sàn, như nó đã từng.

Đối với một API, tôi nghĩ rằng việc khoan hồng cũng giống như đối với một chương trình. Đầu vào vẫn sai , nhưng bạn đang cố gắng sửa chữa càng nhiều càng tốt. Sự khác biệt là những gì được coi là sửa chữa hợp lệ . Như bạn chỉ ra, API nhẹ nhàng có thể gây ra sự cố khi mọi người sử dụng "tính năng" không tồn tại.

Tất nhiên, API chỉ là phiên bản cấp thấp hơn của quy tắc sáng tác . Như vậy, nó thực sự được bảo vệ theo quy tắc ít bất ngờ nhất , vì nó là một giao diện.

Như trích dẫn từ Spencer lưu ý, tránh sự tương đồng bề ngoài, có thể tranh cãi về đầu vào "mờ". Trong những điều kiện này, tôi thường lập luận rằng mọi thứ đều chỉ ra chương trình là không thể sửa chữa, bởi vì nó sẽ không biết điều gì là mong muốn và điều đó ít gây ngạc nhiên nhất cho cơ sở người dùng.

Tuy nhiên, bạn đang xử lý các ngày có nhiều "tiêu chuẩn". Đôi khi những thứ này thậm chí được trộn lẫn trong một chương trình (chuỗi). Vì bạn biết rằng một ngày được mong đợi, cố gắng nhận ra ngày chỉ là thiết kế tốt. Đặc biệt là nếu ngày đến từ một số chương trình bên ngoài và được thông qua không thay đổi qua một giây trên đường đến với bạn.

Các chương trình được triển khai đến máy chủ, hầu hết thời gian, được cho là nhận hàng ngàn yêu cầu mỗi phút, hoặc đôi khi mỗi giây. Nếu một chương trình máy chủ chấp nhận và sửa lỗi đầu vào bị lỗi từ máy khách, tôi e rằng nó sẽ có 2 nhược điểm:

1. Mất thời gian máy chủ quý giá. Với hơn 1000 yêu cầu mỗi giây, việc kiểm tra lỗi trong từng yêu cầu có thể phản ánh trong phản hồi chậm cho từng khách hàng.
2. Không công bằng cho khách hàng / chương trình khách hàng cung cấp đầu vào chính xác. Ngoài ra, khi một lập trình viên phía máy chủ ngồi trên mã máy chủ, anh ấy / cô ấy phải suy nghĩ về các trường hợp khác nhau về những gì đầu vào bị lỗi có thể. Ai sẽ quyết định điều đó?

Các chương trình máy chủ không nên chấp nhận đầu vào bị lỗi, nhưng các máy chủ sẽ trả về một thông báo lỗi cho máy khách, nếu có một đầu vào bị lỗi.

Hành vi lý tưởng, về mặt khái niệm, là làm những gì có thể được thực hiện một cách an toàn, đồng thời đảm bảo rằng ai đó có thể khắc phục bất kỳ vấn đề nào được thông báo bằng cách nào đó về họ. Trong thực tế, tất nhiên, các ràng buộc sau thường không thể gặp trực tiếp, và vì vậy câu hỏi trở nên tốt nhất để đối phó với các đầu vào đáng ngờ.

Một điều có thể rất hữu ích trong việc thiết kế giao thức, định dạng thông số kỹ thuật hoặc "ngôn ngữ" là có một phương tiện để phân biệt bốn loại mục không hiểu tiềm năng:

1. Những điều cần được lọc ra nếu không hiểu.
2. Những điều nên được bỏ qua nếu không hiểu, nhưng dù sao vẫn được giữ lại nếu dữ liệu cần được truyền lại (có lẽ trong một loại trình bao bọc nào đó để chỉ ra rằng nó đã trải qua ít nhất một giai đoạn không hiểu nó)
3. Những điều sẽ tạo cảnh báo nếu không hiểu, nhưng không nên ngăn nỗ lực phục hồi dữ liệu (ví dụ: trong một trang web, một đối tượng có loại không xác định, nhưng phần cuối của tệp được xác định rõ, có thể được hiển thị màu đỏ "X" mà không ngăn phần còn lại của trang được hiển thị.)
4. Những điều sẽ chỉ ra rằng bất cứ điều gì không thể hiểu chúng đều có thể có vấn đề nghiêm trọng và không thể phục hồi ở nơi khác (ví dụ: một chỉ báo cho thấy dữ liệu còn lại bị nén và bất cứ điều gì có thể hiểu được bằng bất cứ điều gì có thể thực hiện giải nén được yêu cầu).

Có một quy ước được xác định rõ ràng theo đó các ứng dụng có thể đọc bất kỳ phiên bản định dạng dữ liệu nào sẽ có thể nhận ra loại nào phù hợp với mọi thứ được tạo theo các phiên bản sau là cách tiếp cận tốt hơn nhiều so với cố gắng nêm vào các biện pháp tương thích ad-hoc sau này Ví dụ: nếu một định dạng tệp có các dòng có dạng "Thẻ: Giá trị", người ta có thể chỉ định rằng ký tự đầu tiên của bất kỳ thẻ nào sẽ chỉ ra danh mục mà nó thuộc về; đối với các thẻ thuộc danh mục bỏ qua im lặng, người ta có thể có ký tự đầu tiên cũng cho biết phiên bản của tiêu chuẩn mà thẻ dự kiến ​​sẽ hợp lệ (để nếu thẻ "bỏ qua im lặng" xuất hiện trong phiên bản 3 của tiêu chuẩn, trình phân tích cú pháp cho phiên bản sẽ âm thầm bỏ qua nó, nhưng trình phân tích cú pháp cho phiên bản 3 trở lên sẽ vặn vẹo nếu không thể phân tích cú pháp).

Điều quan trọng nhất trong mọi trường hợp là tránh chuyển đổi dữ liệu mơ hồ hoặc bị hiểu lầm thành dữ liệu sai. Trong một số trường hợp, có thể tốt hơn là từ chối tuyên truyền dữ liệu mơ hồ, mặc dù trong các trường hợp khác, tốt hơn là truyền nó chính xác như đã nhận trong trường hợp người nhận coi đó là không rõ ràng. Điều thực sự nguy hiểm nếu không hoàn toàn xấu xa là việc chuyển đổi dữ liệu bằng các giả định khác nhau, ví dụ: chuyển đổi danh sách các ngày như:

01/12/12
13/12/12
99/12/12

vào một danh sách các ngày như

2012-01-12
2012-12-13
1999-12-12

Ngay cả khi một người có một danh sách với một vài ngày nhập sai, thì con người có thể đưa ra một danh sách ở định dạng ban đầu để xác định định dạng nào là chính xác và gắn cờ các giá trị đáng ngờ để nghiên cứu thêm (kiểm tra các bản ghi khác, v.v. ) Tuy nhiên, hiển thị các ngày ở định dạng sau, tuy nhiên, sẽ vô vọng và không thể cắt xén chúng.

Trải nghiệm UI của tôi chủ yếu đến từ các hệ thống máy tính để bàn. Các trang web là khác nhau, mặc dù tôi đã thấy một vài trang web có thể thách thức một hệ thống máy tính để bàn. Nhưng với những gì đáng giá:

Tôi thấy rằng các thông báo lỗi phải là giải pháp cuối cùng; một hệ thống lý tưởng sẽ không có chúng ở tất cả. Điều tốt nhất để làm là không cho phép các mục xấu ở vị trí đầu tiên: người dùng không thể nhập "màu xanh lá cây" nếu anh ta chọn từ danh sách thả xuống của tháng. Anh ta không thể nhấn nút màu xám.

Điều tốt nhất tiếp theo cần làm là chấp nhận dữ liệu xấu. Giả sử bạn đang hiển thị biểu đồ doanh số hàng ngày trong một tháng. Sau khi người dùng nhập vào, biểu đồ bao gồm một thế kỷ và thanh một thế kỷ cao hơn 10 lần so với những người khác. Người dùng bây giờ biết anh ta đã làm gì đó sai và, hơn nữa , biết nhiều hơn về những gì anh ta đã làm sai hơn bất kỳ tin nhắn nào có thể nói với anh ta. Khi mục nhập là đồ họa - ví dụ bằng cách kéo chuột - loại phản hồi này vẫn hoạt động và là vô giá. Một loạt các đầu vào có thể không hợp lệ, nhưng sử dụng phương pháp này, người dùng sẽ nhận được phản hồi tức thì, chi tiết về kết quả của từng vị trí chuột.

Tất cả những gì đã nói, đôi khi người dùng cần biết lý do tại sao nút màu xám để anh ta không thể ấn nó. Sau đó, không có sự giúp đỡ cho nó (nếu có là , cho tôi biết) nhưng để ungray nút và khi ông nhấp chuột vào nó, cho anh ta một lời giải thích tốt về lý do tại sao các nút không hoạt động vào lúc này.

Tuyên bố là về việc gửi thông tin qua internet. Một trong những điều với việc gửi thông tin qua internet là không phải lúc nào nó cũng sẽ đến được mục tiêu hay bị phân mảnh.

Một cái gì đó dường như bị bỏ lỡ ở đây - hậu quả của sự thất bại là gì?

Hiển thị một trang web? Bạn nên làm mọi thứ có thể để chịu đựng đầu vào xấu. Lựa chọn của bạn là hiển thị những gì bạn có thể hoặc đưa ra lỗi. Khóa học thứ hai không cung cấp cho người dùng bất cứ điều gì và do đó chỉ nên là phương sách cuối cùng vì nó mang lại cho người dùng một kết quả hoàn toàn vô dụng, sẽ rất khó để một lỗi nghiêm trọng hơn điều này.

Mặt khác, nếu nó yêu cầu mục tiêu của Minuteman III, bạn sẽ từ chối "Moscow" làm đầu vào vì nó có khả năng mơ hồ.