क्या अपवादों को पकड़ना / फेंकना एक शुद्ध विधि अशुद्धता है?

Question

निम्नलिखित कोड उदाहरण मेरे प्रश्न का संदर्भ प्रदान करते हैं।

कक्ष वर्ग को एक प्रतिनिधि के साथ आरंभ किया जाता है। कक्ष वर्ग के पहले कार्यान्वयन में, अपवादों को फेंकने वाले प्रतिनिधियों के खिलाफ कोई गार्ड नहीं हैं। इस तरह के अपवाद उत्तर संपत्ति तक पहुंच जाएंगे, जहां प्रतिनिधि का मूल्यांकन किया जाता है (ध्यान दें: मुख्य () विधि दर्शाती है कि क्लाइंट कोड में एक कक्ष उदाहरण का उपयोग कैसे किया जाता है):

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 () नाम की एक स्थिर फैक्ट्री विधि का परिचय देता हूं। यह विधि प्रतिनिधि द्वारा फेंके गए अपवाद को पकड़ती है, और एक रैपर अपवाद को फेंक देती है, जिसमें एक सार्थक अपवाद संदेश होता है:

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;
    }
}

कोशिश-पकड़ने ब्लॉक रेंडर () विधि अशुद्ध प्रस्तुत करता है?

Comments

कक्ष बनाएँ फ़ंक्शन का लाभ क्या है; यदि आपका प्रतिनिधि एक प्रतिनिधि का उपयोग कर रहा है, तो ग्राहक 'नॉर्थ' कॉल करने से पहले उसे क्यों कॉल करें?

— SH-

@SH यदि प्रतिनिधि अपवाद छोड़ता है, तो मैं कक्ष ऑब्जेक्ट के निर्माण पर पता लगाना चाहता हूं। मैं नहीं चाहता कि ग्राहक उपयोग पर अपवाद को ढूंढें, बल्कि निर्माण पर। बनाएँ विधि दुष्ट प्रतिनिधियों को उजागर करने के लिए सही जगह है।

— रॉक एंथनी जॉनसन

@RockAnthonyJohnson, हाँ। प्रतिनिधि को निष्पादित करते समय आप क्या करते हैं, केवल पहली बार काम कर सकते हैं, या दूसरी कॉल पर एक अलग कमरा वापस कर सकते हैं? प्रतिनिधि को बुलाने पर विचार किया जा सकता है?

— SH-

एक फ़ंक्शन जो अशुद्ध फ़ंक्शन को कॉल करता है वह एक अशुद्ध फ़ंक्शन है, इसलिए यदि प्रतिनिधि अशुद्ध है, तो Createयह भी अशुद्ध है, क्योंकि यह इसे कॉल करता है।

— इदं आर्य

Createसंपत्ति मिलने पर आपका कार्य आपको अपवाद होने से बचाता नहीं है। यदि आपके प्रतिनिधि को फेंक दिया जाता है, तो वास्तविक जीवन में यह बहुत संभावना है कि यह केवल कुछ शर्तों के तहत फेंक दिया जाएगा। संभावना है कि फेंकने की शर्तें निर्माण के दौरान मौजूद नहीं हैं, लेकिन वे संपत्ति प्राप्त करते समय मौजूद हैं।

— बार्ट वैन इनगेन शेनौ

Answer 1

हाँ। यह प्रभावी रूप से एक अशुद्ध कार्य है। यह एक साइड-इफ़ेक्ट बनाता है: प्रोग्राम का निष्पादन उस जगह के अलावा कहीं और जारी रहता है, जहाँ से फ़ंक्शन के लौटने की उम्मीद की जाती है।

इसे एक शुद्ध कार्य करने के लिए, returnएक वास्तविक वस्तु जो फ़ंक्शन से अपेक्षित मान और एक संभावित त्रुटि स्थिति को इंगित करती है, जैसे Maybeऑब्जेक्ट या कार्य ऑब्जेक्ट की एक इकाई।

Comments

याद रखें, "शुद्ध" केवल एक परिभाषा है। यदि आपको एक फ़ंक्शन की आवश्यकता है जो फेंकता है, लेकिन हर दूसरे तरीके से यह संदर्भित रूप से पारदर्शी है, तो आप यही लिखते हैं।

— रॉबर्ट हार्वे

हैस्केल में कम से कम कोई भी फ़ंक्शन फेंक सकता है लेकिन आपको पकड़ने के लिए IO में होना होगा, एक शुद्ध फ़ंक्शन जिसे कभी-कभी फेंकता है उसे सामान्य रूप से आंशिक

— jk

मुझे आपकी टिप्पणी के कारण एक प्रसंग आया है। जबकि मैं बौद्धिक रूप से पवित्रता से घिरी हुई हूं, मुझे वास्तव में व्यावहारिकता की आवश्यकता है, नियतत्ववाद और श्रद्धेय पारदर्शिता है। अगर मैं पवित्रता हासिल करता हूं, तो यह सिर्फ एक अतिरिक्त बोनस है। धन्यवाद। FYI करें, जिस चीज़ ने मुझे इस रास्ते से नीचे ले जाया है वह तथ्य यह है कि Microsoft IntelliTest केवल उस कोड के विरुद्ध प्रभावी है जो नियतात्मक है।

— रॉक एंथनी जॉनसन

@RockAnthonyJohnson: ठीक है, सभी कोड को नियतात्मक होना चाहिए, या कम से कम नियतात्मक होना चाहिए । उस नियतत्व को प्राप्त करने के लिए प्रासंगिक पारदर्शिता केवल एक तरीका है। थ्रेड्स जैसी कुछ तकनीकों में उस नियतत्ववाद के खिलाफ काम करने की प्रवृत्ति होती है, इसलिए टास्क जैसी अन्य तकनीकें भी हैं जो थ्रेडिंग मॉडल के गैर-निर्धारक प्रवृत्ति को बेहतर बनाती हैं। यादृच्छिक संख्या जनरेटर और मोंटे-कार्लो सिमुलेटर जैसी चीजें भी नियतात्मक हैं, लेकिन संभावनाओं के आधार पर एक अलग तरीके से।

— रॉबर्ट हार्वे

@zzzzBov: मैं उस सभी महत्वपूर्ण "शुद्ध" की वास्तविक, सख्त परिभाषा पर विचार नहीं करता। ऊपर दूसरी टिप्पणी

— रॉबर्ट हार्वे

Answer 2

खैर, हां ... और नहीं।

एक शुद्ध फ़ंक्शन में रेफ़रेंशियल ट्रांसपेरेंसी होनी चाहिए - यही है, आपको प्रोग्राम के व्यवहार को बदलने के बिना, किसी भी संभावित कॉल को दिए गए मान के साथ शुद्ध फ़ंक्शन में बदलने में सक्षम होना चाहिए। ^* आपका फ़ंक्शन कुछ तर्कों के लिए हमेशा फेंकने की गारंटी है, इसलिए फ़ंक्शन कॉल को बदलने के लिए कोई वापसी मान नहीं है, इसलिए इसके बजाय इसे अनदेखा करें । इस कोड पर विचार करें:

{
    var ignoreThis = func(arg);
}

यदि funcशुद्ध है, तो एक आशावादी निर्णय func(arg)ले सकता है कि इसे परिणाम के साथ बदल दिया जा सकता है। यह अभी तक नहीं पता है कि परिणाम क्या है, लेकिन यह बता सकता है कि इसका उपयोग नहीं किया जा रहा है - इसलिए यह सिर्फ इस कथन को काट सकता है इसका कोई प्रभाव नहीं है और इसे हटा दें।

लेकिन अगर func(arg)फेंकने के लिए होता है, तो यह कथन कुछ करता है - यह एक अपवाद फेंकता है! इसलिए ऑप्टिमाइज़र इसे हटा नहीं सकता है - इससे कोई फर्क नहीं पड़ता है कि फ़ंक्शन को कॉल किया जाता है या नहीं।

परंतु...

व्यवहार में, यह बहुत कम मायने रखता है। एक अपवाद - कम से कम C # में - कुछ असाधारण है। आप इसे अपने नियमित नियंत्रण प्रवाह के भाग के रूप में उपयोग करने वाले नहीं हैं - आप इसे आज़माना चाहते हैं और इसे पकड़ना चाहते हैं, और यदि आप कुछ पकड़ते हैं तो या तो आप जो कर रहे थे या किसी तरह अभी भी इसे पूरा करने के लिए त्रुटि को संभालते हैं। यदि आपका प्रोग्राम ठीक से काम नहीं करता है, क्योंकि एक कोड जो विफल हो गया था, उसे दूर अनुकूलित किया गया था, तो आप अपवादों का गलत उपयोग कर रहे हैं (जब तक कि यह परीक्षण कोड नहीं है, और जब आप परीक्षण अपवादों को अनुकूलित नहीं किया जाना चाहिए)।

ऐसा कहे जाने के बाद...

इस उद्देश्य के साथ कि वे पकड़े जाएंगे, इस उद्देश्य के साथ शुद्ध कार्यों से अपवाद न फेंकें - एक अच्छा कारण है कि कार्यात्मक भाषाएं स्टैक-अनइंडिंग-अपवादों के बजाय मठों का उपयोग करना पसंद करती हैं।

यदि C # में Errorजावा (और कई अन्य भाषाओं) की तरह एक वर्ग होता, तो मैं Errorइसके बजाय फेंकने का सुझाव देता Exception। यह इंगित करता है कि फ़ंक्शन के उपयोगकर्ता ने कुछ गलत किया (एक फ़ंक्शन जो फेंकता है) पारित कर दिया, और शुद्ध कार्यों में ऐसी चीजों की अनुमति है। लेकिन C # में एक Errorवर्ग नहीं है , और उपयोग की त्रुटि अपवाद से प्राप्त होती है Exception। मेरा सुझाव एक फेंकना है ArgumentException, यह स्पष्ट करते हुए कि फ़ंक्शन को एक बुरे तर्क के साथ बुलाया गया था।

---

^* _{कम्प्यूटेशनल रूप से बोलना। भोली पुनरावृत्ति का उपयोग करके कार्यान्वित एक फाइबोनैचि फ़ंक्शन बड़ी संख्या में लंबे समय तक ले जाएगा, और मशीन के संसाधनों को समाप्त कर सकता है, लेकिन चूंकि असीम समय और स्मृति के साथ फ़ंक्शन हमेशा एक ही मान लौटाएगा और इसके साइड-इफेक्ट्स नहीं होंगे (आवंटन के अलावा अन्य) मेमोरी और उस मेमोरी को बदल देना) - यह अभी भी शुद्ध माना जाता है।}

Comments

+1 ArgumentException के आपके सुझाए गए उपयोग के लिए, और आपकी अनुशंसा के लिए "शुद्ध कार्यों से अपवादों को इस इरादे से न फेंकें कि वे पकड़े जाएंगे"।

— रॉक एंथोनी जॉनसन

आपका पहला तर्क ("लेकिन ..." तक) मेरे लिए असत्य लगता है। अपवाद फ़ंक्शन के अनुबंध का हिस्सा है। आप वैचारिक रूप से किसी भी फ़ंक्शन को फिर से लिख सकते हैं (value, exception) = func(arg)और एक अपवाद को फेंकने की संभावना को दूर कर सकते हैं (कुछ भाषाओं में और कुछ प्रकार के अपवादों के लिए आपको वास्तव में इसे परिभाषा के साथ सूचीबद्ध करने की आवश्यकता है, जैसे कि तर्क या वापसी मूल्य)। अब यह पहले की तरह ही शुद्ध होगा (बशर्ते कि यह हमेशा रिटर्न उर्फ ​​थ्रो एक अपवाद को समान तर्क देता हो)। यदि आप इस व्याख्या का उपयोग करते हैं तो अपवाद फेंकना कोई साइड इफेक्ट नहीं है।

— anoE

@ यदि आप इस funcतरह से लिखते हैं , तो जो ब्लॉक मैंने दिया है वह दूर अनुकूलित किया जा सकता है, क्योंकि स्टैक को हटाने के बजाय फेंके गए अपवाद को इनकोड नहीं किया गया होता ignoreThis, जिसे हम नजरअंदाज कर देते हैं। इसके अतिरिक्त, जो स्टैक को खोलते हैं, अपवाद रिटर्न प्रकार में एन्कोडेड शुद्धता का उल्लंघन नहीं करते हैं - और यही कारण है कि कई कार्यात्मक भाषाएं उनका उपयोग करना पसंद करती हैं।

— ईडन आर्य

बिल्कुल सही ... आपने इस काल्पनिक परिवर्तन के अपवाद को नजरअंदाज नहीं किया होगा। मुझे लगता है कि यह सब शब्दार्थ / परिभाषा के एक मुद्दे का एक सा है, मैं सिर्फ यह बताना चाहता था कि अपवादों के अस्तित्व या घटना को जरूरी नहीं कि पवित्रता की सभी धारणाओं से शून्य किया जाए।

— AnoE

@AnoE लेकिन मैंने जो कोड लिखा है वह इस कल्पित परिवर्तन के अपवाद को अनदेखा करेगा । func(arg)tuple को लौटाएगा (<junk>, TheException()), और इसलिए ignoreThistuple सम्‍मिलित होगा (<junk>, TheException()), लेकिन चूंकि हम कभी ignoreThisभी अपवाद का उपयोग नहीं करते हैं इसलिए किसी भी चीज पर कोई प्रभाव नहीं पड़ेगा।

— इदन आर्य

Answer 3

एक विचार यह है कि कोशिश - पकड़ ब्लॉक मुद्दा नहीं है। (उपरोक्त प्रश्न के लिए मेरी टिप्पणियों के आधार पर)।

मुख्य समस्या यह है कि उत्तर संपत्ति एक I / O कॉल है ।

कोड के निष्पादन में उस बिंदु पर, क्लाइंट कोड द्वारा प्रदान किए गए I / O की जांच करने के लिए प्रोग्राम की आवश्यकता होती है। (यह प्रासंगिक नहीं होगा कि इनपुट एक प्रतिनिधि के रूप में है, या यह कि इनपुट नाममात्र का था, पहले से ही पारित हो चुका है)।

एक बार जब आप इनपुट का नियंत्रण खो देते हैं, तो आप यह सुनिश्चित नहीं कर सकते कि फ़ंक्शन शुद्ध है। (खासकर यदि फ़ंक्शन फेंक सकता है)।

---

मैं स्पष्ट नहीं हूं कि आप मूव [चेक] रूम पर कॉल की जांच क्यों नहीं करना चाहते हैं? प्रश्न के लिए मेरी टिप्पणी के अनुसार:

हाँ। प्रतिनिधि को निष्पादित करते समय आप क्या करते हैं, केवल पहली बार काम कर सकते हैं, या दूसरी कॉल पर एक अलग कमरा वापस कर सकते हैं? प्रतिनिधि को बुलाने पर विचार किया जा सकता है?

जैसा कि बार्ट वैन इनगेन शेनौ ने कहा,

संपत्ति बनाते समय आपका क्रिएट फंक्शन आपको अपवाद होने से बचाता नहीं है। यदि आपके प्रतिनिधि को फेंक दिया जाता है, तो वास्तविक जीवन में यह बहुत संभावना है कि यह केवल कुछ शर्तों के तहत फेंक दिया जाएगा। संभावना है कि फेंकने की शर्तें निर्माण के दौरान मौजूद नहीं हैं, लेकिन वे संपत्ति प्राप्त करते समय मौजूद हैं।

सामान्य तौर पर, किसी भी प्रकार का आलसी लोडिंग उस बिंदु तक त्रुटियों को स्पष्ट रूप से परिभाषित करता है।

---

मैं एक मूव [चेक] रूम विधि का उपयोग करने का सुझाव दूंगा। यह आपको एक स्थान पर अशुद्ध I / O पहलुओं को अलग करने की अनुमति देगा।

करने के लिए इसी तरह के रॉबर्ट हार्वे के जवाब:

इसे एक शुद्ध फ़ंक्शन बनाने के लिए, एक वास्तविक ऑब्जेक्ट लौटाएं जो फ़ंक्शन से अपेक्षित मान और एक संभावित त्रुटि स्थिति को इंगित करने वाला मान, जैसे शायद ऑब्जेक्ट या कार्य ऑब्जेक्ट की एक इकाई लौटाता है।

यह कोड लेखक पर निर्भर करेगा कि वह इनपुट से (संभव) अपवाद को कैसे संभाल सकता है। फिर विधि एक कक्ष ऑब्जेक्ट, या अशक्त कक्ष ऑब्जेक्ट वापस कर सकती है, या शायद अपवाद को बुलबुला कर सकती है।

यह इस बिंदु पर निर्भर करता है:

• क्या कक्ष डोमेन कमरे के अपवादों को अशक्त या कुछ बुरा मानता है।
• उत्तर को एक अशक्त / अपवाद कक्ष पर कॉल करने वाले क्लाइंट कोड को कैसे सूचित करें। (जमानत / स्थिति परिवर्तनीय / वैश्विक राज्य / वापसी एक मोनाड / जो भी; कुछ अधिक शुद्ध हैं तो अन्य :)।

Answer 4

हम्म ... मुझे इस बारे में सही नहीं लगा। मुझे लगता है कि आप जो करने की कोशिश कर रहे हैं वह यह सुनिश्चित करने के लिए है कि दूसरे लोग अपना काम सही तरीके से करें, बिना यह जाने कि वे क्या कर रहे हैं।

चूंकि फ़ंक्शन उपभोक्ता द्वारा पारित किया जाता है, जिसे आपके द्वारा या अन्य व्यक्ति द्वारा लिखा जा सकता है।

क्या होगा यदि फ़ंक्शन पास उस समय चलने के लिए मान्य नहीं है जब कक्ष ऑब्जेक्ट बनाया जाता है?

कोड से, मुझे यकीन नहीं हो रहा था कि उत्तर क्या कर रहा है।

मान लीजिए, यदि फ़ंक्शन कमरे को बुक करने के लिए है, और इसे बुकिंग के समय और अवधि की आवश्यकता है, तो आपको जानकारी तैयार नहीं होने पर अपवाद मिलेगा।

क्या होगा अगर यह एक लंबे समय तक चलने वाला कार्य है? आप एक कक्ष ऑब्जेक्ट बनाते समय अपने प्रोग्राम को ब्लॉक नहीं करना चाहेंगे, यदि आपको 1000 रूम ऑब्जेक्ट बनाने की आवश्यकता है तो क्या होगा?

यदि आप वह व्यक्ति थे जो इस वर्ग का उपभोग करने वाले उपभोक्ता को लिखेंगे, तो आप सुनिश्चित करेंगे कि जो फ़ंक्शन पास किया गया है वह सही ढंग से लिखा गया है, क्या आप नहीं करेंगे?

यदि कोई अन्य व्यक्ति है जो उपभोक्ता लिखता है, तो वह / वह एक कक्ष ऑब्जेक्ट बनाने की "विशेष" स्थिति को नहीं जान सकता है, जो निष्पादन का कारण बन सकता है और वे पता लगाने की कोशिश कर रहे अपने सिर को खरोंच कर देंगे।

एक और बात, नए अपवाद को फेंकना अच्छी बात नहीं है। कारण यह है कि इसमें मूल अपवाद की जानकारी नहीं होगी। आप जानते हैं कि आपको एक त्रुटि मिलती है (जेनेरिक अपवाद के लिए एक अनुकूल मैसेज), लेकिन आपको नहीं पता होगा कि त्रुटि क्या है (अशक्त संदर्भ, बाध्यता से बाहर सूचकांक, शून्य आदि से विभाजित)। यह जानकारी बहुत महत्वपूर्ण है जब हमें जांच करने की आवश्यकता होती है।

आपको अपवाद तभी संभालना चाहिए जब आप जानते हैं कि इसे क्या और कैसे संभालना है।

मुझे लगता है कि आपका मूल कोड काफी अच्छा है, एकमात्र बात यह है कि आप "मेन" पर अपवाद को संभालना चाहते हैं (या किसी भी परत को पता होगा कि इसे कैसे संभालना है)।

Comments

2 कोड उदाहरण पर फिर से देखें; मैं निम्न अपवाद के साथ नए अपवाद को प्रारंभ करता हूं। संपूर्ण स्टैक ट्रेस संरक्षित है।

— रॉक एंथनी जॉनसन

उफ़। मेरी गलती।

— user251630

Answer 5

मैं दूसरे जवाबों से असहमत होकर कहूंगा कि नहीं । अपवाद नहीं तो शुद्ध कार्य अशुद्ध हो जाता है।

त्रुटि परिणामों के लिए स्पष्ट जांच का उपयोग करने के लिए अपवादों के किसी भी उपयोग को फिर से लिखा जा सकता है। अपवादों को इसके ऊपर सिंटैक्टिक शुगर माना जा सकता है। सुविधाजनक सिंथैटिक शुगर शुद्ध कोड अशुद्ध नहीं बनाता है।

Comments

तथ्य यह है कि आप अशुद्धता को फिर से लिख सकते हैं फ़ंक्शन को शुद्ध नहीं बनाता है। हास्केल एक प्रमाण है कि अशुद्ध कार्यों के उपयोग को शुद्ध कार्यों के साथ फिर से लिखा जा सकता है - यह रिटर्न प्रकार के शुद्ध शुद्ध कार्यों में किसी भी अशुद्ध व्यवहार को एनकोड करने के लिए साधुओं का उपयोग करता है। IO सन्यासी का अस्तित्व यह नहीं दर्शाता है कि नियमित IO शुद्ध है - अपवाद भिक्षुओं के अस्तित्व का अर्थ यह क्यों होना चाहिए कि नियमित अपवाद शुद्ध हैं?

— इदं आर्य

@IdanArye: मैं तर्क दे रहा हूं कि पहली जगह में कोई अशुद्धता नहीं है। पुनर्लेखन का उदाहरण सिर्फ यह प्रदर्शित करना था। नियमित IO अशुद्ध है क्योंकि यह देखने योग्य दुष्प्रभाव का कारण बनता है, या कुछ बाहरी इनपुट के कारण एक ही इनपुट के साथ विभिन्न मान वापस कर सकता है। एक अपवाद को फेंकना उन चीजों में से कोई भी नहीं करता है।

— जैक्सबी

साइड-इफ़ेक्ट फ़्री कोड पर्याप्त नहीं है। फंक्शन प्योरिटी के लिए रेफरेंशियल ट्रांसपेरेंसी भी एक आवश्यकता है।

— ईडन आर्ये

संदर्भात्मक पारदर्शिता के लिए नियतत्ववाद पर्याप्त नहीं है - साइड-इफेक्ट्स भी निर्धारक हो सकते हैं। रेफ़रेंशियल ट्रांसपेरेंसी का मतलब है कि अभिव्यक्ति को इसके परिणामों से बदला जा सकता है - इसलिए कोई फर्क नहीं पड़ता कि आप कितनी बार संदर्भात्मक पारदर्शी अभिव्यक्तियों का मूल्यांकन करते हैं, किस क्रम में, और क्या आप उनका मूल्यांकन करते हैं या नहीं - परिणाम समान होना चाहिए। यदि कोई अपवाद निर्दिष्‍ट रूप से फेंका जाता है तो हम "चाहे कितनी भी बार" मापदंड के साथ अच्छे हों, लेकिन अन्य लोगों के साथ नहीं। मैंने अपने स्वयं के उत्तर में "या नहीं" मानदंड के बारे में तर्क दिया है, (कॉन ...)

— इदन आर्ये

(... शेष भाग) और "किस क्रम में" के लिए के रूप में - अगर fऔर gदोनों शुद्ध कार्य हैं, तो f(x) + g(x)एक ही परिणाम आपको मूल्यांकन की परवाह किए बिना होना चाहिए f(x)और g(x)। लेकिन अगर f(x)फेंकता है Fऔर g(x)फेंकता है G, तो इस अभिव्यक्ति से फेंका गया अपवाद यह होगा कि पहले मूल्यांकन किया Fजाए f(x)और Gयदि g(x)पहले मूल्यांकन किया जाए - तो यह नहीं है कि शुद्ध कार्यों को कैसे व्यवहार किया जाना चाहिए! जब अपवाद रिटर्न प्रकार में एन्कोड किया जाता है, तो यह परिणाम Error(F) + Error(G)मूल्यांकन आदेश के स्वतंत्र रूप से कुछ के रूप में समाप्त हो जाएगा ।

— इदं आर्य