เซิร์ฟเวอร์ควร“ ผ่อนปรน” ในสิ่งที่ควรยอมรับและ“ ทิ้งอินพุตที่ผิดพลาดอย่างเงียบ ๆ ” หรือไม่?

ฉันอยู่ภายใต้ความประทับใจที่ตอนนี้ทุกคนเห็นด้วยกับความจริงข้อนี้เป็นความผิดพลาด แต่เมื่อเร็ว ๆ นี้ฉันเห็นคำตอบนี้ซึ่งมีความคิดเห็นแบบ "ผ่อนปรน" เพิ่มขึ้น 137 ครั้ง (ณ วันนี้)

ในความเห็นของฉันการผ่อนปรนในสิ่งที่เบราว์เซอร์ยอมรับนั้นเป็นสาเหตุโดยตรงของความยุ่งเหยิงที่สุดที่ HTML และมาตรฐานเว็บอื่น ๆ เมื่อไม่กี่ปีที่ผ่านมาและเพิ่งจะเริ่มตกผลึกของระเบียบนั้นอย่างเหมาะสม วิธีที่ฉันเห็นมันการผ่อนปรนในสิ่งที่คุณยอมรับจะนำไปสู่สิ่งนี้

ส่วนที่สองของ maxim คือ"ทิ้งอินพุตที่ผิดพลาดอย่างเงียบ ๆ โดยไม่ส่งคืนข้อความแสดงข้อผิดพลาดยกเว้นว่าข้อกำหนดนี้จำเป็นสำหรับข้อมูลจำเพาะ"และสิ่งนี้จะทำให้เกิดความไม่พอใจกับแนวเขตแดน โปรแกรมเมอร์คนใดคนหนึ่งกระแทกหัวของพวกเขาบนผนังเมื่อมีบางอย่างล้มเหลวเงียบ ๆ จะรู้ว่าฉันหมายถึงอะไร

ดังนั้นฉันผิดอย่างสมบูรณ์เกี่ยวกับเรื่องนี้? โปรแกรมของฉันควรจะผ่อนปรนในสิ่งที่ยอมรับและกลืนข้อผิดพลาดอย่างเงียบ ๆ หรือไม่? หรือฉันตีความผิด ๆ ว่าสิ่งนี้ควรจะหมายถึงอะไร?

คำถามเดิมกล่าวว่า "โปรแกรม" และฉันจะชี้ให้ทุกคนเห็นว่า มันสมเหตุสมผลสำหรับโปรแกรมที่จะผ่อนปรน อย่างไรก็ตามสิ่งที่ฉันหมายถึงจริงๆก็คือ API: ส่วนต่อประสานที่เปิดรับกับโปรแกรมอื่นมากกว่าคน HTTP เป็นตัวอย่าง โพรโทคอลเป็นอินเทอร์เฟซที่ใช้เฉพาะโปรแกรมอื่น ผู้คนไม่เคยระบุวันที่ที่เป็นส่วนหัวโดยตรงเช่น "If-Modified-Since"

ดังนั้นคำถามคือ: เซิร์ฟเวอร์ที่ใช้มาตรฐานควรผ่อนปรนและอนุญาตให้ใช้วันที่ในรูปแบบอื่น ๆ นอกเหนือจากที่มาตรฐานกำหนดไว้จริงหรือไม่ ฉันเชื่อว่า "ผ่อนปรน" ควรจะนำไปใช้กับสถานการณ์นี้มากกว่าการเชื่อมต่อของมนุษย์

ถ้าเซิร์ฟเวอร์ที่ผ่อนปรนมันอาจจะดูเหมือนการปรับปรุงโดยรวม แต่ฉันคิดว่าในทางปฏิบัติมันเพียง แต่นำไปสู่การใช้งานของลูกค้าที่จบลงด้วยการอาศัยในความเอื้อเฟื้อเผื่อแผ่และทำให้ล้มเหลวในการทำงานร่วมกับเซิร์ฟเวอร์อื่นที่ผ่อนปรนในรูปแบบที่แตกต่างกันเล็กน้อย

ดังนั้นเซิร์ฟเวอร์ที่เปิดเผย API บางตัวควรผ่อนปรนหรือเป็นความคิดที่แย่มาก?

ตอนนี้เข้าสู่การจัดการข้อมูลผู้ใช้ที่ผ่อนปรน พิจารณา YouTrack (ซอฟต์แวร์ติดตามบั๊ก) มันใช้ภาษาสำหรับการป้อนข้อความที่เตือนให้รำลึกถึง Markdown ยกเว้นว่าเป็น "ผ่อนปรน" ตัวอย่างเช่นการเขียน

- foo
- bar
- baz

คือไม่ได้เป็นวิธีที่ได้รับการบันทึกในการสร้างรายการที่มีสัญลักษณ์และยังทำงาน ดังนั้นมันจึงถูกนำมาใช้อย่างมากในเครื่องมือติดตามบั๊กของเรา รุ่นถัดไปจะออกมาและคุณสมบัติผ่อนปรนนี้จะเริ่มทำงานแตกต่างกันเล็กน้อยโดยแยกรายการต่าง ๆ ที่ (mis) ใช้คุณลักษณะนี้ (ไม่ใช่) วิธีที่ทำเป็นเอกสารเพื่อสร้างรายการสัญลักษณ์แสดงหัวข้อยังคงใช้งานได้แน่นอน

ดังนั้นซอฟต์แวร์ของฉันควรจะผ่อนปรนในสิ่งที่ผู้ใช้ป้อนมันยอมรับ

แน่นอนว่าคุณพูดถูก โปรแกรมไม่ควร "ผ่อนปรน" เนื่องจากจะทำหน้าที่เพื่อปกปิดปัญหาเท่านั้น ควรเน้นปัญหาที่เกิดขึ้นอย่ากวาดใต้พรม ข้อความแสดงข้อผิดพลาดเป็นข้อมูลที่จำเป็นอย่างยิ่งสำหรับโปรแกรมที่จะเป็นประโยชน์ต่อผู้ใช้

ส่วนใหญ่เวลาที่มีการให้ข้อมูลที่ไม่ถูกต้อง / ไม่ถูกต้องผู้ให้บริการของข้อมูลนั้น (ไม่ว่าจะเป็นผู้ใช้หรือผลลัพธ์ของโปรแกรมอื่น) อาจไม่รู้ว่ามันไม่ถูกต้อง การกลืนข้อผิดพลาดจะทำให้พวกเขาอยู่ในความเชื่อว่ามันเป็น (หรืออาจจะ) ที่ถูกต้องซึ่ง proliferates ข้อมูลที่ไม่ถูกต้อง

วิธีเดียวสำหรับระบบที่จะทำงานร่วมกันคือเพื่อให้การทำงานร่วมกันนั้นได้รับการกำหนดอย่างสมบูรณ์และไม่น่าสงสัย โปรแกรมที่รับข้อมูลนอกสเปคทำให้ data de factoยอมรับแม้ว่าจะไม่ถูกต้องโดยสเป็คซึ่งไม่เพียง แต่ทำให้ความเข้ากันได้เป็นภาระมากขึ้น แต่ยังหมายความว่ามันไม่ได้กำหนดอย่างเป็นทางการอีกต่อไป ตัวโปรแกรมเองตอนนี้เป็นมาตรฐานอย่างแท้จริง ดังนั้นโปรแกรมแบบผ่อนปรนจะไม่สามารถพัฒนาเพิ่มเติมหรือแทนที่ได้เนื่องจากคุณไม่สามารถทำการเปลี่ยนแปลงขั้นต่ำสุดได้ว่ามันทำงานอย่างไร

ฉันคิดว่าทุกอย่างขึ้นอยู่กับว่ากลุ่มประชากรเป้าหมายของคุณคือใคร หากเป็นโปรแกรมเมอร์ก็ไม่ได้อย่างแน่นอน โปรแกรมของคุณควรล้มเหลวอย่างหนักและกรีดร้องด้วยการฆาตกรรมนองเลือด อย่างไรก็ตามหากกลุ่มเป้าหมายของคุณไม่ใช่โปรแกรมเมอร์ดังนั้นโปรแกรมของคุณควรจะผ่อนปรนในจุดที่สามารถจัดการกับข้อยกเว้นได้อย่างสง่างาม

เป็นกรณีศึกษานำเครื่องเล่นแฟลช NPAPI มีรุ่น "ปล่อย" สำหรับผู้ที่ไม่สนใจเกี่ยวกับข้อผิดพลาด 99% ที่อาจเกิดขึ้นได้ แต่ยังมีรุ่น "ดีบั๊ก" ที่สามารถใช้ในการกรีดร้องการฆาตกรรมนองเลือดเมื่อมีอะไรผิดปกติ แต่ละการสนับสนุนการเล่นเนื้อหา Flash อย่างชัดเจน แต่ถูกกำหนดเป้าหมายไปยังกลุ่มประชากรสองกลุ่มที่แตกต่างกันโดยสิ้นเชิง

ในท้ายที่สุดฉันคิดว่าสิ่งที่สำคัญคือ: ผู้ใช้ของคุณสนใจอะไร

มี "ผ่อนปรน" สองประเภท: หนึ่งคือการยอมรับอินพุตที่ไม่ถูกต้องและพยายามทำความเข้าใจกับมันและอีกประเภทหนึ่งคือการยอมรับอินพุตที่แตกต่างกัน

โดยทั่วไปคุณต้องการอันดับที่สองเสมอเมื่อเป็นไปได้ สิ่งแรกคือเมื่อคุณตายเร็วและแรง ตัวอย่าง: วันที่

ต่อไปนี้เป็นตัวอย่างอินพุตที่ถูกต้องไม่ถูกต้องและคลุมเครือ

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

Greenมีเพียงคนเดียวที่ไม่ถูกต้องป้อนข้อมูลที่นี่: อย่าแม้แต่จะพยายามยอมรับมันเป็นวันที่ เนื่องจากGreenไม่ใช่วันที่แน่นอนจึงเป็นกรณีที่ยอมรับความล้มเหลวเงียบได้

01/02/2011ถูกต้อง แต่ไม่ชัดเจน คุณไม่จำเป็นต้องรู้ว่ามันถูกป้อนเป็นวันที่สหรัฐอเมริกา (2 มกราคม) หรือไม่ (1 กุมภาพันธ์) ที่นี่อาจเป็นการดีที่สุดที่จะล้มเหลวเสียงดังและขอให้ผู้ใช้สำหรับวันที่ชัดเจน

2011-01-02โดยทั่วไปถือว่าไม่คลุมเครือดังนั้นจึงเป็นเรื่องดีที่จะดำเนินการต่อไปและถือว่าเป็นรูปแบบ "YYYY-MM-DD" และจะล้มเหลวต่อไปเท่านั้น มันเป็นการเรียกใช้วิจารณญาณเล็กน้อยเมื่อต้องจัดการกับอินพุตของผู้ใช้

Jan 2, 2011และ2-Jan-2011ถูกต้องและชัดเจนพวกเขาควรได้รับการยอมรับ อย่างไรก็ตามThe Second of January of the year 2011มันก็ใช้ได้และไม่คลุมเครือ แต่การทำเช่นนั้นเพื่อความเอื้อเฟื้อเผื่อแผ่นั้นเกินความจริง Greenไปข้างหน้าและล้มเหลวมันเงียบเช่นเดียวกับ

ในระยะสั้นคำตอบคือ "มันขึ้นอยู่กับ" ดูสิ่งที่ป้อนได้และตรวจสอบให้แน่ใจว่าคุณไม่เคยรับประเภทอินพุตที่ขัดแย้งกัน (เช่นDD/MM/YYYYvs MM/DD/YYYY)

ในบริบทของการเชื่อมโยงคำถาม / ความคิดเห็น2011-01-02นั่นคือกรณีของ อินพุตดูเหมือน JSON และจะตรวจสอบเช่น JSON แม้ว่าชนิด mime จะไม่ถูกต้อง ไปข้างหน้าและพยายามที่จะใช้มันแม้ว่ามันจะล้มเหลวในบางจุดลงไปที่เส้น

ความล้มเหลวในความเงียบเป็นสิ่งที่เลวร้ายที่สุดที่คุณสามารถทำได้ คุณได้ลองแก้จุดบกพร่อง API ด้วยความล้มเหลวที่เงียบ มันเป็นไปไม่ได้

มี "พยายามอย่างเต็มที่ในการกู้คืน แต่ส่งข้อผิดพลาดโดยละเอียด" และ "ความล้มเหลวเงียบ"

สำหรับผมแล้วดูเหมือนว่ากฎของ Postel - "จงระมัดระวังในสิ่งที่คุณทำมีความเป็นอิสระในสิ่งที่คุณยอมรับจากผู้อื่น" คือสิ่งที่ถูกกล่าวถึงสำหรับบริการ JSON โดยปกติจะใช้กับเว็บเซอร์วิสไม่ใช่ UI

สำหรับข้อเสนอแนะของผู้ใช้ UI ที่สร้างสรรค์และการป้อนข้อมูลผู้ใช้ที่ขัดแย้งกันคือกฎง่ายๆที่เราใช้

ฉันคิดว่านี่ครอบคลุมในบทที่ 1 ตอนที่ 6ของ TAOUP โดยเฉพาะกฎของการซ่อมแซมซึ่งระบุว่าโปรแกรมที่ควรจะทำอะไรที่มันสามารถมีการป้อนข้อมูลที่ส่งผ่านข้อมูลที่ถูกต้องไปข้างหน้าและถ้าตอบที่ถูกต้องคือความล้มเหลวแล้วจะทำเช่นนั้นให้เร็วที่สุด

แนวคิดที่คล้ายกันคือการเขียนโปรแกรมการป้องกัน คุณไม่ทราบว่าคุณจะได้รับข้อมูลประเภทใด แต่โปรแกรมของคุณควรมีความทนทานเพียงพอที่จะครอบคลุมทุกกรณี ซึ่งหมายความว่าควรตั้งโปรแกรมในกรณีกู้คืนสำหรับปัญหาที่ทราบเช่นอินพุต mangled และตรวจจับทุกกรณีเพื่อจัดการกับ unknowns

ดังนั้นทิ้งป้อนข้อมูลผิดพลาดอย่างเงียบ ๆ เป็นเรื่องปกติตราบใดที่คุณมีการจัดการการป้อนข้อมูลที่ คุณไม่ควรวางมันลงบนพื้นเหมือนเดิม

สำหรับ API ฉันคิดว่าการผ่อนปรนเหมือนกับโปรแกรม อินพุตยังไม่ถูกต้องแต่คุณพยายามซ่อมแซมให้มากที่สุด ความแตกต่างเป็นสิ่งที่ถือว่าถูกต้องซ่อมแซม เมื่อคุณชี้ให้เห็นว่า API แบบผ่อนปรนอาจทำให้เกิดปัญหาเมื่อผู้คนใช้ "คุณสมบัติ" ที่ไม่มีอยู่

ของหลักสูตร API เป็นเพียงรุ่นที่ต่ำกว่าระดับของการปกครองขององค์ประกอบ เช่นนี้มันได้รับการคุ้มครองภายใต้กฎของความประหลาดใจน้อยที่สุดเนื่องจากเป็นส่วนต่อประสาน

ในฐานะที่เป็นคำพูดจากบันทึกของ Spencer หลีกเลี่ยงความคล้ายคลึงกันแบบผิวเผิน ภายใต้เงื่อนไขเหล่านี้ฉันมักจะยืนยันว่าทุกอย่างชี้ไปที่โปรแกรมที่ไม่สามารถซ่อมแซมได้เพราะมันจะไม่รู้ว่าอะไรเป็นสิ่งที่ต้องการ

อย่างไรก็ตามคุณกำลังติดต่อกับวันที่ซึ่งมี "มาตรฐาน" มากมาย บางครั้งสิ่งเหล่านี้ยังปะปนอยู่ในโปรแกรมเดียว เมื่อคุณรู้ว่าคาดว่าจะมีการออกเดทการพยายามจดจำวันที่เป็นเพียงการออกแบบที่ดี โดยเฉพาะอย่างยิ่งหากวันที่นั้นมาจากโปรแกรมภายนอกและได้รับการแก้ไขโดยไม่ผ่านการแก้ไขวินาทีในแบบของคุณ

โปรแกรมที่มีการปรับใช้กับเซิร์ฟเวอร์โดยส่วนใหญ่จะใช้เวลานับพันคำขอทุกนาทีหรือบางครั้งทุกวินาที หากโปรแกรมเซิร์ฟเวอร์ยอมรับและแก้ไขอินพุตที่ผิดพลาดจากไคลเอนต์ฉันกลัวว่ามันจะมีข้อเสีย 2 ประการ:

1. สูญเสียเวลาอันมีค่าของเซิร์ฟเวอร์ ด้วย 1,000+ คำขอต่อวินาทีการตรวจสอบข้อบกพร่องในแต่ละคำขอสามารถสะท้อนให้เห็นถึงการตอบสนองช้าสำหรับลูกค้าแต่ละราย
2. ไม่เป็นธรรมกับไคลเอ็นต์ / โปรแกรมไคลเอ็นต์ที่ให้อินพุตที่ถูกต้อง นอกเหนือจากนั้นเมื่อโปรแกรมเมอร์ฝั่งเซิร์ฟเวอร์ตั้งอยู่บนรหัสเซิร์ฟเวอร์เขา / เธอจะต้องคิดถึงหลายกรณีของอินพุตที่ผิดพลาดใด ๆ ใครจะเป็นผู้ตัดสินใจ

โปรแกรมเซิร์ฟเวอร์ไม่ควรยอมรับอินพุตที่ผิดพลาด แต่เซิร์ฟเวอร์ควรส่งคืนข้อความแสดงข้อผิดพลาดไปยังไคลเอ็นต์หากมีอินพุตที่ผิดพลาด

พฤติกรรมในอุดมคติแนวคิดรวบยอดคือการทำสิ่งที่สามารถทำได้อย่างปลอดภัยในขณะเดียวกันก็ทำให้มั่นใจได้ว่าใครบางคนที่สามารถแก้ไขปัญหาใด ๆ จะได้รับแจ้งเกี่ยวกับพวกเขา ในทางปฏิบัติแน่นอนว่าข้อ จำกัด หลัง ๆ นั้นมักจะเป็นไปไม่ได้ที่จะพบกันโดยตรงและดังนั้นคำถามจะดีที่สุดในการจัดการกับปัจจัยที่น่าสงสัย

สิ่งหนึ่งที่มีประโยชน์มากในการออกแบบโพรโทคอลการจัดรูปแบบข้อมูลจำเพาะหรือ "ภาษา" คือการแยกแยะรายการที่อาจเกิดจากสินค้าที่ไม่เข้าใจสี่ประเภท

1. สิ่งที่ควรกรองหากไม่เข้าใจ
2. สิ่งที่ควรละเว้นหากไม่เข้าใจ แต่ยังคงเก็บไว้หากข้อมูลต้องถูกส่งผ่าน (อาจเป็นรูปแบบของ wrapper เพื่อระบุว่ามันผ่านขั้นตอนอย่างน้อยหนึ่งขั้นที่ไม่เข้าใจ)
3. สิ่งที่ควรสร้างคำเตือนหากไม่เข้าใจ แต่ไม่ควรป้องกันความพยายามในการกู้คืนข้อมูล (เช่นในหน้าเว็บวัตถุที่ไม่ทราบประเภท แต่มีจุดสิ้นสุดภายในไฟล์ที่กำหนดไว้อย่างดีอาจแสดงเป็นสีแดง "X" โดยไม่มีการป้องกันการแสดงผลส่วนที่เหลือของหน้า)
4. สิ่งที่จะบ่งชี้ว่าสิ่งที่ไม่สามารถเข้าใจได้นั้นมีแนวโน้มที่จะมีปัญหาที่รุนแรงและไม่สามารถกู้คืนได้ที่อื่น (เช่นตัวบ่งชี้ว่าข้อมูลที่เหลืออยู่นั้นถูกบีบอัดและสิ่งใดที่จะเข้าใจได้โดยสิ่งใดก็ตาม

การมีระเบียบปฏิบัติที่กำหนดไว้อย่างชัดเจนว่าแอพใดที่สามารถอ่านเวอร์ชันใด ๆ ของรูปแบบข้อมูลจะสามารถรับรู้ได้ว่าหมวดหมู่ใดที่เหมาะสมสำหรับสิ่งใดก็ตามที่สร้างโดยสอดคล้องกับรุ่นที่ใหม่กว่าเป็นวิธีที่ดีกว่าการพยายามวัดความเข้ากันได้แบบเฉพาะกิจ หลังจากนั้น. ตัวอย่างเช่นหากรูปแบบไฟล์มีบรรทัดในรูปแบบ "Tag: Value" สามารถระบุได้ว่าอักขระตัวแรกของแท็กใด ๆ จะระบุหมวดหมู่ที่เป็นของมัน สำหรับแท็กของหมวดหมู่การเพิกเฉยต่อความเงียบอาจมีตัวอักษรตัวแรกที่ระบุเวอร์ชันของมาตรฐานที่คาดว่าแท็กนั้นจะใช้งานได้ (ดังนั้นหากมีแท็ก "เงียบเพิกเฉย" ที่อ้างว่ามีอยู่ในเวอร์ชัน 3 ของ มาตรฐานตัวแยกวิเคราะห์สำหรับเวอร์ชันจะเพิกเฉยต่อความเงียบ แต่ตัวแยกวิเคราะห์สำหรับเวอร์ชัน 3 หรือใหม่กว่านั้นจะเบลอถ้าไม่สามารถแยกวิเคราะห์ได้)

สิ่งที่สำคัญที่สุดในทุกกรณีคือหลีกเลี่ยงการแปลงข้อมูลที่คลุมเครือหรือเข้าใจผิดให้เป็นข้อมูลที่ผิดพลาด ในบางกรณีมันอาจเป็นการดีกว่าที่จะปฏิเสธที่จะเผยแพร่ข้อมูลที่คลุมเครือ แต่ในกรณีอื่น ๆ มันอาจจะเป็นการดีกว่าที่จะเผยแพร่อย่างแม่นยำตามที่ได้รับในกรณีที่ผู้รับจะถือว่ามันไม่ชัดเจน สิ่งที่เป็นอันตรายอย่างแท้จริงหากไม่ใช่ความชั่วร้ายอย่างสิ้นเชิงคือการแปลงข้อมูลโดยใช้สมมติฐานที่แตกต่างกันเช่นการแปลงรายการวันที่เช่น:

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

ลงในรายการวันที่ที่ต้องการ

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

แม้ว่าจะมีรายการที่มีวันที่ที่ป้อนผิดสองสามคนก็อาจเป็นไปได้ที่มนุษย์จะได้รับรายการในรูปแบบดั้งเดิมเพื่อกำหนดรูปแบบที่ถูกต้องและตั้งค่าสถานะที่น่าสงสัยสำหรับการวิจัยเพิ่มเติม (ตรวจสอบกับบันทึกอื่น ๆ ฯลฯ ) ) การแสดงวันที่ในรูปแบบหลังจะทำให้เกิดความสับสนและสิ้นหวัง

ประสบการณ์ UI ของฉันส่วนใหญ่มาจากระบบเดสก์ท็อป เว็บไซต์ต่างกัน แต่ฉันเคยเห็นเว็บไซต์ไม่กี่แห่งที่สามารถท้าทายระบบเดสก์ท็อป แต่สำหรับสิ่งที่คุ้มค่า:

ฉันพบว่าข้อความแสดงข้อผิดพลาดควรเป็นทางเลือกสุดท้าย ระบบในอุดมคติจะไม่มีพวกเขาเลย สิ่งที่ดีที่สุดที่ต้องทำคือไม่อนุญาตให้มีรายการที่ไม่ดีในตอนแรก: ผู้ใช้ไม่สามารถป้อน "สีเขียว" ถ้าเขาเลือกจากรายการแบบเลื่อนลงของเดือน เขาไม่สามารถกดปุ่มสีเทา

สิ่งที่ดีที่สุดถัดไปที่ต้องทำคือยอมรับข้อมูลที่ไม่ดี สมมติว่าคุณแสดงฮิสโตแกรมของยอดขายรายวันเป็นเวลาหนึ่งเดือน หลังจากที่ผู้ใช้ป้อนข้อมูลกราฟจะครอบคลุมหนึ่งศตวรรษและแถบหนึ่งศตวรรษนั้นสูงกว่าครั้งอื่น ๆ ถึง 10 เท่า ตอนนี้ผู้ใช้รู้ว่าเขาทำอะไรผิดและยิ่งกว่านั้นรู้อะไรมากมายเกี่ยวกับสิ่งที่เขาทำผิดไปกว่าข้อความใด ๆ ก็สามารถบอกเขาได้ เมื่อรายการเป็นภาพกราฟิก - โดยการลากเมาส์ตัวอย่างเช่น - ข้อเสนอแนะประเภทนี้ยังคงทำงานและมีคุณค่า กลุ่มของอินพุตอาจไม่ถูกต้อง แต่การใช้วิธีนี้ผู้ใช้จะได้รับผลตอบรับแบบทันทีโดยละเอียดเกี่ยวกับผลลัพธ์ของตำแหน่งเมาส์แต่ละตำแหน่ง

ทั้งหมดที่กล่าวว่าบางครั้งผู้ใช้จำเป็นต้องรู้ว่าทำไมปุ่มจึงเป็นสีเทาเพื่อให้เขาไม่สามารถกด จากนั้นก็มีความช่วยเหลือมันไม่มี (ถ้ามีคือแจ้งให้เราทราบ) แต่ ungray ปุ่มและเมื่อเขาคลิกที่มันให้เขาคำอธิบายที่ดีว่าทำไมปุ่มไม่ทำงานในขณะนี้

คำสั่งนี้เกี่ยวกับการส่งข้อมูลผ่านอินเทอร์เน็ต สิ่งหนึ่งที่มีการส่งข้อมูลผ่านอินเทอร์เน็ตคือมันจะไม่ไปถึงเป้าหมายเลยหรือแยกส่วน

สิ่งที่ดูเหมือนจะพลาดที่นี่ - อะไรคือผลของความล้มเหลว

แสดงหน้าเว็บ? คุณควรทำทุกอย่างเท่าที่ทำได้เพื่อให้ทนกับข้อมูลที่ไม่ดี ตัวเลือกของคุณคือการแสดงสิ่งที่คุณสามารถหรือโยนข้อผิดพลาด หลักสูตรหลังนี้ไม่ให้สิ่งใดแก่ผู้ใช้และควรเป็นทางเลือกสุดท้ายเนื่องจากจะให้ผลลัพธ์ที่ไร้ประโยชน์กับผู้ใช้อย่างสมบูรณ์มันจะค่อนข้างยากสำหรับข้อผิดพลาดที่จะแย่กว่านี้

ในทางกลับกันถ้ามันถามถึงเป้าหมายของ Minuteman III คุณก็ปฏิเสธ "มอสโคว์" ว่าเป็นอินพุตเพราะมันอาจคลุมเครือ