เหตุใดตัวเลือก / อาจถือว่าเป็นความคิดที่ดีและข้อยกเว้นที่ตรวจสอบแล้วไม่ได้

ภาษาการเขียนโปรแกรมบางอย่างเช่น Scala มีแนวคิดของOptionประเภท (เรียกอีกอย่างว่าMaybe) ซึ่งสามารถมีค่าหรือไม่

จากสิ่งที่ฉันได้อ่านเกี่ยวกับพวกเขาพวกเขาได้รับการพิจารณาอย่างกว้างขวางว่าเป็นวิธีที่ดีกว่าในการจัดการกับปัญหานี้มากกว่าnullเพราะพวกเขาบังคับให้โปรแกรมเมอร์พิจารณากรณีที่อาจไม่มีค่าแทนที่จะระเบิดในระหว่างรันไทม์

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

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

เพราะOptions เป็นองค์ประกอบ มีจำนวนมากของวิธีการที่เป็นประโยชน์ในมีOptionที่ให้คุณสามารถเขียนโค้ดรัดกุมในขณะที่ยังช่วยให้การควบคุมที่แม่นยำในการไหล: map, flatMap, toList, flattenและอื่น ๆ นี่เป็นเพราะความจริงที่ว่าOptionเป็น monad ชนิดหนึ่งวัตถุบางอย่างที่เรารู้ดีว่าจะเขียนได้อย่างไร หากคุณไม่ได้มีวิธีการเหล่านี้และต้องจับคู่รูปแบบตลอดเวลาOptionหรือโทรisDefinedบ่อย ๆ พวกเขาอาจไม่ได้มีประโยชน์เท่าที่ควร

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

ในขณะที่เกี่ยวข้องข้อยกเว้นและวัตถุอาจไม่ได้จัดการกับปัญหาประเภทเดียวกัน

ข้อยกเว้น

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

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

อาจจะเป็นวัตถุ

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

ข้อได้เปรียบของวัตถุบางทีคือคุณประกาศอย่างชัดเจนว่ามีบางอย่างผิดปกติ ใน Haskell วัตถุที่ไม่ใช่อาจจะต้องมีค่ามิฉะนั้นโปรแกรมจะไม่รวบรวม

ปัญหาเกี่ยวกับประเภท nullable คือคุณต้องตรวจสอบ null ตลอดเวลาเพื่อความปลอดภัยอย่างแน่นอน สถานะ "บางสิ่งอาจผิดปกติ" คือสถานะเริ่มต้น

ปัญหาเกี่ยวกับรหัสส่งคืน + ส่งโดย apis คือพวกเขาไม่สามารถอ่านได้สำหรับคนส่วนใหญ่

เพราะด้วยMaybeคุณสามารถชะลอการจัดการข้อผิดพลาดจนกว่าคุณจะต้องการค่าจริง (ซึ่งอาจเป็นวิธีการบางอย่างที่โทรออก)

ในขณะที่การยกเว้นการตรวจสอบความต้องการที่จะจัดการในสถานที่โทร

สิ่งเดียวที่ทำให้เกิดข้อยกเว้นคือข้อมูลเพิ่มเติมสามารถส่งผ่านเกี่ยวกับสาเหตุที่มันล้มเหลว (เว้นแต่มีคนพัฒนาMaybeErrorด้วยเขตข้อมูลที่สามารถโยนได้เมื่อเกิดข้อผิดพลาด)