การจับ / การโยนข้อยกเว้นทำให้วิธีการที่บริสุทธิ์นั้นไม่บริสุทธิ์หรือไม่?

ตัวอย่างโค้ดต่อไปนี้ให้บริบทกับคำถามของฉัน

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

public sealed class Room
{
    private readonly Func<Room> north;

    public Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = new Room(north: evilDelegate);

        var room = kitchen.North; //<----this will throw

    }
}

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

public sealed class Room
{
    private readonly Func<Room> north;

    private Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static Room Create(Func<Room> north)
    {
        try
        {
            north?.Invoke();
        }
        catch (Exception e)
        {
            throw new Exception(
              message: "Initialized with an evil delegate!", innerException: e);
        }

        return new Room(north);
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = Room.Create(north: evilDelegate); //<----this will throw

        var room = kitchen.North;
    }
}

บล็อก try-catch แสดงวิธีสร้าง () ไม่บริสุทธิ์หรือไม่

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

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

ใช่แล้ว ... และไม่ใช่

ฟังก์ชั่นที่บริสุทธิ์จะต้องมีReferential Transparency - นั่นคือคุณควรจะสามารถแทนที่การเรียกไปยังฟังก์ชั่นที่บริสุทธิ์ด้วยค่าที่ส่งกลับโดยไม่เปลี่ยนพฤติกรรมของโปรแกรม ^*ฟังก์ชั่นของคุณมีการประกันเพื่อเสมอโยนข้อโต้แย้งบางอย่างดังนั้นจึงไม่มีค่าตอบแทนที่จะเปลี่ยนฟังก์ชั่นการโทรด้วยดังนั้นแทนที่จะขอไม่สนใจมัน พิจารณารหัสนี้:

{
    var ignoreThis = func(arg);
}

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

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

แต่...

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

ที่ถูกกล่าวว่า ...

อย่าโยนข้อยกเว้นจากฟังก์ชั่นที่บริสุทธิ์ด้วยความตั้งใจว่าจะถูกจับได้ - มีเหตุผลที่ดีที่ภาษาการใช้งานต้องการใช้ monads แทนที่จะเป็น stack-unwinding-exceptions

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

^* _{การพูดเชิงคำนวณ ฟังก์ชั่นฟีโบนักชีนำมาใช้โดยใช้การเรียกซ้ำแบบไร้เดียงสาจะใช้เวลานานสำหรับจำนวนมากและอาจทำให้ทรัพยากรของเครื่องหมดไป แต่สิ่งเหล่านี้เนื่องจากด้วยเวลาที่ไม่ จำกัด และหน่วยความจำฟังก์ชั่นจะคืนค่าเดิมเสมอ หน่วยความจำและเปลี่ยนหน่วยความจำนั้น) - มันยังถือว่าบริสุทธิ์}

สิ่งหนึ่งที่ควรพิจารณาคือบล็อก try-catch ไม่ใช่ปัญหา (ขึ้นอยู่กับความคิดเห็นของฉันกับคำถามข้างต้น)

ปัญหาหลักคือการที่นอร์ทเป็น I / O โทร

ณ จุดนั้นในการเรียกใช้โค้ดโปรแกรมจำเป็นต้องตรวจสอบ I / O ที่ได้จากรหัสลูกค้า (มันจะไม่เกี่ยวข้องว่าข้อมูลที่อยู่ในรูปแบบของผู้ได้รับมอบหมายหรือว่าการป้อนข้อมูลในนามในนามผ่านไปแล้ว)

เมื่อคุณสูญเสียการควบคุมอินพุตคุณไม่สามารถมั่นใจได้ว่าฟังก์ชั่นนั้นบริสุทธิ์ (โดยเฉพาะถ้าฟังก์ชั่นสามารถโยนได้)

ฉันไม่ชัดเจนว่าทำไมคุณไม่ต้องการตรวจสอบการโทรเพื่อย้าย [ตรวจสอบ] ห้อง? ตามความคิดเห็นของฉันกับคำถาม:

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

ดังที่ Bart van Ingen Schenau กล่าวไว้ข้างต้น

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

โดยทั่วไปการโหลดแบบสันหลังยาว ใด ๆโดยปริยาย defersข้อผิดพลาดจนกว่าจะถึงจุดนั้น

ฉันขอแนะนำให้ใช้วิธีการย้าย [ตรวจสอบ] ห้อง สิ่งนี้จะช่วยให้คุณสามารถแยกแง่มุม I / O ที่ไม่บริสุทธิ์ออกเป็นที่เดียว

คล้ายกับคำตอบของ Robert Harvey :

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

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

ตอนนี้มันขึ้นอยู่กับ:

• โดเมน Room ปฏิบัติต่อข้อยกเว้นของห้องพักว่าเป็นโมฆะหรือบางสิ่งบางอย่างเลวร้ายยิ่งขึ้นหรือไม่
• วิธีแจ้งรหัสลูกค้าที่โทรไปยัง North บนห้อง Null / Exception (การประกันตัว / สถานะตัวแปร / รัฐทั่วโลก / คืน Monad / อะไร; บางอย่างบริสุทธิ์มากขึ้นแล้วอื่น ๆ :))

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

เนื่องจากฟังก์ชั่นถูกส่งผ่านโดยผู้บริโภคซึ่งสามารถเขียนโดยคุณหรือโดยบุคคลอื่น

จะเกิดอะไรขึ้นถ้าฟังก์ชั่นการส่งผ่านไม่สามารถทำงานได้ในเวลาที่วัตถุห้องถูกสร้างขึ้น

จากรหัสฉันไม่แน่ใจว่าสิ่งที่นอร์ทกำลังทำอยู่

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

ถ้ามันเป็นฟังก์ชั่นที่ใช้งานได้นาน คุณจะไม่ต้องการปิดกั้นโปรแกรมของคุณในขณะที่สร้างวัตถุห้องถ้าคุณจำเป็นต้องสร้างวัตถุ 1,000 ห้อง?

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

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

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

คุณควรจัดการข้อยกเว้นเฉพาะเมื่อคุณรู้ว่าจะต้องจัดการอะไรและอย่างไร

ฉันคิดว่ารหัสดั้งเดิมของคุณดีพอสิ่งเดียวคือคุณอาจต้องการจัดการกับข้อยกเว้นใน "หลัก" (หรือเลเยอร์ใด ๆ ที่รู้วิธีจัดการ)

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

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