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

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

การอ้างอิงแบบ Null ไม่ได้ "หลบเลี่ยง" มากกว่าข้อยกเว้นอย่างน้อยก็มีใครบางคนที่ฉันรู้จักหรือเคยอ่าน ฉันคิดว่าคุณเข้าใจผิดเกี่ยวกับภูมิปัญญาดั้งเดิม

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

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

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

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

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

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

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

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

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

โทนีฮอร์ที่สร้างความคิดของการอ้างอิงโมฆะในสถานที่แรกที่เรียกว่าความผิดพลาดหนึ่งล้านดอลลาร์

ปัญหาไม่ได้เกี่ยวกับการอ้างอิงที่เป็นโมฆะต่อการค้นหา แต่เกี่ยวกับการขาดการตรวจสอบประเภทที่เหมาะสมในภาษาที่ปลอดภัย (ส่วนใหญ่) ประเภทการพิมพ์

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

ปัญหานี้มีอยู่โดยเฉพาะอย่างยิ่งใน C หรือ C ++ (ตัวอย่าง) เนื่องจากข้อผิดพลาด "ยาก" ที่ทำให้เกิด (ความผิดพลาดของโปรแกรมทันทีโดยไม่มีการกู้คืนที่สวยงาม)

ในภาษาอื่นมีคำถามเกี่ยวกับวิธีจัดการกับมันเสมอ

ใน Java หรือ C # คุณจะได้รับข้อยกเว้นหากคุณพยายามเรียกใช้เมธอดในการอ้างอิงแบบ null และอาจไม่เป็นไร ดังนั้นโปรแกรมเมอร์ Java หรือ C # ส่วนใหญ่จึงคุ้นเคยกับสิ่งนี้และไม่เข้าใจว่าทำไมจึงต้องการทำอย่างอื่น (และหัวเราะที่ C ++)

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

จริงๆแล้วมันคือการถกเถียงข้อผิดพลาดรหัส / ข้อยกเว้นเก่า แต่คราวนี้ด้วยSentinel Valueแทนข้อผิดพลาดรหัส

แล้วแต่ความเหมาะสมที่สุดขึ้นอยู่กับสถานการณ์และความหมายที่คุณกำลังมองหา

คุณไม่สามารถแนบข้อความแสดงข้อผิดพลาดที่มนุษย์อ่านได้เข้ากับตัวชี้โมฆะ

(อย่างไรก็ตามคุณสามารถฝากข้อความข้อผิดพลาดไว้ในไฟล์บันทึก)

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

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

การคืนค่า NULL (หรือศูนย์ตัวเลขหรือบูลีน false) เพื่อส่งสัญญาณข้อผิดพลาดนั้นผิดทั้งในเชิงเทคนิคและเชิงแนวคิด

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

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

ในอดีตมีการรายงานข้อผิดพลาดด้วยวิธีนี้เนื่องจากภาษาการเขียนโปรแกรมเช่น C ไม่มีการจัดการข้อยกเว้นอยู่ในภาษาและวิธีที่แนะนำ (โดยใช้การข้ามแบบยาว) นั้นค่อนข้างลำบาก

นอกจากนี้ยังมีปัญหาด้านการบำรุงรักษาด้วยข้อยกเว้นคุณต้องเขียนโค้ดเพิ่มเติมเพื่อจัดการกับความล้มเหลว ถ้าคุณทำไม่ได้โปรแกรมจะล้มเหลวเร็วและแรง (ซึ่งถือว่าดี) หากคุณคืนค่า NULL เป็นสัญญาณข้อผิดพลาดพฤติกรรมเริ่มต้นของโปรแกรมคือการละเว้นข้อผิดพลาดและดำเนินการต่อจนกว่าจะนำไปสู่ปัญหาอื่น ๆ ตามทาง - ข้อมูลเสียหาย segfaults, NullReferenceExceptions ขึ้นอยู่กับภาษา ในการส่งสัญญาณข้อผิดพลาดเร็วและดังคุณต้องเขียนรหัสพิเศษและเดาว่า: อะไรคือส่วนที่เหลือเมื่อคุณถึงกำหนด

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

หากคุณอนุญาตให้พอยน์เตอร์พอยน์เตอร์เป็นกรณีที่ถูกต้องนั่นเป็นกรณีพิเศษ คุณต้องการตรรกะการจัดการกรณีพิเศษซึ่งมักจะอยู่ในสถานที่ต่าง ๆ มากมาย นั่นเป็นความซับซ้อนพิเศษ

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

ความซับซ้อนมากขึ้นมักหมายถึงข้อผิดพลาดเพิ่มเติม

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

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

เจาะจงไปที่ C ++ แต่มีการอ้างอิงแบบ null จะถูกหลีกเลี่ยงเพราะความหมายแบบ null ใน C ++ นั้นสัมพันธ์กับชนิดของตัวชี้ มันค่อนข้างสมเหตุสมผลสำหรับฟังก์ชั่นเปิดไฟล์ที่จะล้มเหลวและส่งกลับตัวชี้โมฆะ; ในความเป็นจริงfopen()ฟังก์ชั่นทำตรงนั้น

มันขึ้นอยู่กับภาษา

ตัวอย่างเช่น Objective-C ช่วยให้คุณส่งข้อความไปยังวัตถุ null (ไม่มี) โดยไม่มีปัญหา การเรียกไปที่ศูนย์จะส่งกลับศูนย์เช่นกันและถือว่าเป็นคุณสมบัติภาษา

ฉันชอบมันเป็นการส่วนตัวเนื่องจากคุณสามารถพึ่งพาพฤติกรรมนั้นและหลีกเลี่ยงการif(obj == null)สร้างซ้อนซ้อนที่ซับซ้อนทั้งหมด

ตัวอย่างเช่น

if (myObject != nil && [myObject doSomething])
{
    ...
}

สามารถย่อให้เหลือ:

if ([myObject doSomething])
{
    ...
}

กล่าวโดยสรุปจะทำให้โค้ดของคุณอ่านง่ายขึ้น

ฉันไม่บีบแตรไม่ว่าคุณจะคืนค่าว่างหรือโยนข้อยกเว้นตราบใดที่คุณบันทึกไว้

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

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

การอ้างอิงแบบ Null มักจะมีประโยชน์มากตัวอย่างเช่นองค์ประกอบในรายการที่เชื่อมโยงสามารถมีตัวตายตัวแทนบางตัวหรือไม่มีตัวตายตัวแทน ใช้nullสำหรับ "ไม่มีตัวตายตัวแทน" เป็นเรื่องปกติอย่างสมบูรณ์ หรือบุคคลสามารถมีคู่ครองหรือไม่ - ใช้nullสำหรับ "คนไม่มีคู่สมรส" เป็นธรรมชาติอย่างสมบูรณ์แบบเป็นธรรมชาติมากกว่าการมีบางคน "ไม่มีคู่สมรส" - ค่าพิเศษที่Person.Spouseสมาชิกสามารถอ้างถึง

แต่: ค่าจำนวนมากไม่ใช่ตัวเลือก ในโปรแกรม OOP ทั่วไปฉันจะบอกว่ามากกว่าครึ่งของการอ้างอิงไม่สามารถเกิดขึ้นได้nullหลังจากการเริ่มต้นมิฉะนั้นโปรแกรมจะล้มเหลว มิฉะนั้นจะต้องมีการif (x != null)ตรวจสอบโค้ด เหตุใดการอ้างอิงทุกรายการจึงควรเป็นโมฆะโดยค่าเริ่มต้น มันควรจะเป็นวิธีอื่น ๆ : ตัวแปรควรไม่เป็นโมฆะโดยค่าเริ่มต้นและคุณควรจะต้องพูดว่า "โอ้และค่านี้ก็ควรจะเป็นnullเช่นกัน"

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