ข้อ จำกัด ด้านความปลอดภัยควรทำให้บริการส่งคืน null หรือมีข้อผิดพลาดหรือไม่? [ปิด]

ฉันกำลังขัดแย้งกับนักพัฒนาที่มีประสบการณ์มากกว่าในเรื่องนี้และสงสัยว่าคนอื่นคิดอย่างไรกับมัน สภาพแวดล้อมของเราคือ Java, EJB 3, บริการและอื่น ๆ

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

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

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

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

ข้อยกเว้นควรถูกโยนทิ้งเมื่อมีข้อผิดพลาดและการขอสิ่งนั้นไม่ใช่ข้อผิดพลาด

การขอสิ่งของอาจไม่ใช่ข้อผิดพลาด แต่การไม่มีสิทธิ์ในสิ่งที่คุณขอนั้นเป็นข้อผิดพลาดบางประเภท ข้อยกเว้นเป็นอีกทางเลือกหนึ่งในการรายงานเงื่อนไขที่ยอดเยี่ยมที่จะใช้แทนค่าส่งคืนพิเศษ (เช่นที่nullซึ่งคุณเขียนไว้จะไม่ช่วยอะไรเลยหากมี> 1 เหตุผลที่เป็นไปได้ว่าทำไมสิ่งต่าง ๆ ถึงผิดพลาด (แม้ว่าจะมี สาเหตุที่เป็นไปได้ 1 ข้อในขณะนี้อาจมี 2 สาเหตุที่เป็นไปได้ในรุ่นถัดไปดังนั้นการใช้nullเป็นค่าที่ส่งคืนเพื่อระบุความล้มเหลว หากบริการไม่ได้รายงานในลักษณะที่ว่าทำไมมันจะไม่ทำสิ่งที่คุณขอมันก็เป็นการออกแบบที่ไม่ดีอย่างแน่นอน

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

String.substring()พ่นIndexOutOfBoundsExceptionถ้าดัชนีอยู่นอกขอบเขต ฉันไม่สามารถคิดถึงข้อดีที่จะกลับมาnullแทนได้แม้ว่า - ในเชิงปรัชญาแล้วใคร ๆ ก็แย้งว่า a Stringไม่ได้มีอะไรนอกเหนือจากขอบเขตดังนั้นnullมันจึงเป็นค่าตอบแทนที่สมเหตุสมผล การมีเหตุผลเชิงปรัชญาและการปฏิบัตินั้นเป็นสัตว์สองชนิดที่แตกต่างกันอย่างชัดเจน

มันลงมาที่สัญญาคืออะไร หากสัญญาของคุณบอกว่าคุณสามารถขอสิ่งที่ไม่มีอยู่ก็ควรจะบอกว่าเกิดอะไรขึ้น (null หรือวัตถุ null)

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

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

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

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

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

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

อย่างไรก็ตามสำหรับการสร้างรายการนั้นเป็นเรื่องที่แตกต่าง สันนิษฐานว่าอาจมีสาเหตุหลายประการที่ทำให้เกิดความล้มเหลว - ไม่มีสิทธิ์พารามิเตอร์ที่ไม่ถูกต้องเซิร์ฟเวอร์ออกจากหน่วยความจำ ฯลฯ หากผู้พัฒนาได้รับค่า null สำหรับเงื่อนไขเหล่านั้นทั้งหมด .

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

ดังนั้นอย่าเข้าไปทำสงครามศาสนากับสิ่งนี้ตัดสินใจสิ่งที่ถูกต้องสำหรับปัญหาเฉพาะนี้

ฉันคิดว่ามันเป็นการออกแบบที่ไม่ดีอย่างแน่นอน Null-pointer ไม่ใช่คำตอบที่ถูกต้องสำหรับฉันและมันอาจยุ่งยากในการจัดการ

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

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

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

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

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

ในทางกลับกันnullคุณกลับทำให้ลูกค้าตรวจสอบสิ่งที่เกิดขึ้น

NullPointerExceptionนอกจากนี้คุณตระหนักว่ามีปัญหาเพราะคุณมีที่อื่น ทีนี้ลองนึกภาพคุณจะไม่เก็บการคืนค่าของฟังก์ชันนั้น ... คุณจะถูกบังคับให้ล้อมรอบการเรียกแต่ละครั้งไปยังฟังก์ชันนั้นด้วยif elseบล็อก ...

จากมุมมองของฉันการกลับมาnullเป็นการฝึกฝนที่ไม่ดี

นักพัฒนาที่มีประสบการณ์มากขึ้นซึ่งเขียนบริการแย้งว่าการขอข้อมูลไม่ใช่เงื่อนไขข้อผิดพลาดและข้อยกเว้นนั้นควรถูกส่งไปในเงื่อนไขข้อผิดพลาดเท่านั้นไม่ใช่เมื่อผู้ใช้ไม่สามารถเข้าถึงข้อมูลได้

จากมุมมองของฉันมันไม่สมเหตุสมผล

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

การเปรียบเทียบ : รหัสการตอบสนองที่GETไม่มีการอนุมัตินั้นไม่ได้200 okไม่มีข้อมูล401 Unauthorizedเลย

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

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

หากสาเหตุที่แท้จริงคือผู้ใช้ที่ไม่ผ่านการรับรองความถูกต้องแล้วฉันต้องการการตอบกลับ HTTP 401 ที่หนักหน่วงบางทีอาจมีการเปลี่ยนเส้นทางไปยังหน้าข้อความสวย ๆ สาเหตุที่เกี่ยวข้องกับการอนุญาตนั้นเป็นกรณี ๆ ไป มีข้อโต้แย้งสำหรับการส่งคืนข้อผิดพลาด HTTP (403, พูด) และข้อโต้แย้งสำหรับการส่งคืนรหัส / ข้อความที่มีรูปแบบพิเศษในการตอบสนองบริการ

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

หากต้องการเล่นผู้สนับสนุนปีศาจฉันจะพยายามกลับมาเป็นโมฆะ

ในความคิดของฉันมีเพียงสถานการณ์เดียวที่การตอบสนองประเภทนี้เกือบจะยอมรับได้และนั่นก็คือในกรณีนี้เมื่อความปลอดภัยมีส่วนเกี่ยวข้อง

มันง่ายมากที่จะให้รายละเอียดของระบบของคุณไปโดยไม่ตั้งใจซึ่งคนที่ไม่ได้รับอนุญาตไม่ควรทราบ สิ่งนี้ควรหลีกเลี่ยง

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

ดังนั้นในกรณีนี้ฉันจะบอกว่ามันเกือบจะโอเคที่จะกลับมาnullแต่ฉันเห็นด้วยมันจะไม่เป็นที่พอใจมากที่จะทำงานกับ

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