एल्म के दावों की तरह "नो रनटाइम अपवाद" होने का क्या लाभ है?

Question

कुछ भाषाओं का दावा है कि अन्य भाषाओं पर एक स्पष्ट लाभ के रूप में "कोई रनटाइम अपवाद नहीं" है।

मैं मामले पर भ्रमित हूं।

रनटाइम अपवाद केवल एक उपकरण है, जहां तक ​​मुझे पता है, और जब इसका अच्छी तरह से उपयोग किया जाता है:

• आप "गंदे" राज्यों से संवाद कर सकते हैं (अप्रत्याशित डेटा पर फेंकना)
• स्टैक जोड़ना आप त्रुटि की श्रृंखला को इंगित कर सकते हैं
• आप अव्यवस्था के बीच अंतर कर सकते हैं (जैसे अमान्य इनपुट पर एक खाली मान लौटाते हुए) और असुरक्षित उपयोग जो कि एक डेवलपर के ध्यान की आवश्यकता है (जैसे अमान्य इनपुट पर अपवाद फेंकना)
• आप डिबगिंग प्रयासों (सैद्धांतिक रूप से) में मदद करने वाले अतिरिक्त उपयोगी विवरण प्रदान करने वाले अपवाद संदेश के साथ अपनी त्रुटि के लिए विवरण जोड़ सकते हैं

दूसरी ओर मुझे एक सॉफ़्टवेयर को डीबग करना वास्तव में कठिन लगता है जो अपवादों को "निगल" करता है। उदाहरण के लिए

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

तो सवाल यह है: "कोई रनटाइम अपवाद नहीं" होने का मजबूत, सैद्धांतिक लाभ क्या है?

---

उदाहरण

https://guide.elm-lang.org/

अभ्यास में कोई रनटाइम त्रुटियाँ नहीं। कोई अशक्त नहीं। कोई अपरिभाषित कोई फ़ंक्शन नहीं है।

Comments

मुझे लगता है कि इस तरह के दावों और / या लिंक का उल्लेख करने वाली भाषाओं में से एक या दो उदाहरण प्रदान करने में मदद मिलेगी। इसकी व्याख्या कई तरीकों से की जा सकती है।

— जिमीजैम

मैंने जो नवीनतम उदाहरण पाया है वह सी, सी ++, सी #, जावा, ईसीएमएस्क्रिप्ट, आदि की तुलना में एल्म था। मैंने अपना प्रश्न @ जिमीजम्स अपडेट किया है

— atoth

यह पहली बार मैंने इसके बारे में सुना है। मेरी पहली प्रतिक्रिया बीएस बुलाने की है। नेवला शब्दों पर ध्यान दें: व्यवहार में

— जिमीजैम

@ मैं इसे स्पष्ट करने के लिए आपके प्रश्न शीर्षक को संपादित करने जा रहा हूं, क्योंकि कई असंबंधित प्रश्न हैं जो इसके समान दिखते हैं (जैसे "RuntimeException" बनाम "अपवाद" जावा में)। यदि आप नए शीर्षक को नापसंद करते हैं, तो इसे फिर से संपादित करने के लिए स्वतंत्र महसूस करें।

— एंड्रेस एफ।

ठीक है, मैं चाहता था कि यह सामान्य हो, लेकिन मैं इस बात पर सहमत हो सकता हूं कि अगर मदद मिलती है, तो आपके योगदान के लिए धन्यवाद @AndFF!

— atoth

Answer 1

अपवादों में शब्दार्थ सीमित होते हैं। उन्हें ठीक उसी जगह संभाला जाना चाहिए जहां उन्हें फेंका गया है, या सीधे कॉल में ऊपर की तरफ स्टैक किया गया है, और यदि आप ऐसा करना भूल जाते हैं, तो संकलन समय पर प्रोग्रामर के लिए कोई संकेत नहीं है।

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

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

निम्नलिखित उदाहरण पर विचार करें। आप इसे http://elm-lang.org/try में पेस्ट कर सकते हैं यदि आप इसे एक्शन में देखना चाहते हैं।

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

फ़ंक्शन String.toIntमें नोट calculateमें विफलता की संभावना है। जावा में, यह एक रनटाइम अपवाद को फेंकने की क्षमता रखता है। जैसा कि यह उपयोगकर्ता इनपुट को पढ़ता है, इसके पास काफी अच्छा मौका है। इसके बजाय एल्म मुझे वापस लौटने के लिए इससे निपटने के लिए मजबूर करता है Result, लेकिन ध्यान दें कि मुझे अभी इससे निपटने की जरूरत नहीं है। मैं इनपुट को दोगुना कर सकता हूं और इसे स्ट्रिंग में बदल सकता हूं, फिरgetDefault फ़ंक्शन में खराब इनपुट की जांच कर सकता हूं । यह स्थान उस बिंदु की तुलना में चेक के लिए बहुत बेहतर है जहां त्रुटि हुई या कॉल स्टैक में ऊपर की तरफ।

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

Comments

That means you get a compiler error if you don't handle the error.- ठीक है, कि जावा में चेक किए गए अपवादों के पीछे तर्क था, लेकिन हम सभी जानते हैं कि कितनी अच्छी तरह से काम किया।

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

@RobertHarvey एक तरह से, जावा के चेक किए गए अपवाद इसके गरीब आदमी के संस्करण थे। दुर्भाग्य से उन्हें "निगल लिया" (जैसे ओपी के उदाहरण में) हो सकता है। वे वास्तविक प्रकार भी नहीं थे, जिससे उन्हें कोड प्रवाह के लिए एक अतिरिक्त अतिरिक्त मार्ग बना दिया गया। बेहतर प्रकार सिस्टम के साथ बोली प्रथम श्रेणी के मूल्यों, है जो आप में (जैसे) के रूप में कर एनकोड त्रुटियों के साथ हास्केल की अनुमति Maybe, Either, ऐसा लगता है आदि एल्म दिखता है इस तरह के एमएल, OCaml या हास्केल के रूप में भाषाओं से एक पृष्ठ पर ले रहा है।

— एंड्रेस एफ।

@ जिमीजम्स नहीं, वे आपको बाध्य नहीं करते हैं। जब आप मूल्य का उपयोग करना चाहते हैं तो आपको केवल "हैंडल" करना होगा। अगर मैं ऐसा x = some_func(), मैं नहीं करना है कुछ भी करने को जब तक कि मैं के मूल्य की जांच करना चाहते x, जिस स्थिति में मैं देख सकते हैं कि मैं एक त्रुटि या एक "वैध" मूल्य है; इसके अलावा, यह एक स्थिर प्रकार की त्रुटि है जो एक के स्थान पर दूसरे का उपयोग करने का प्रयास करती है, इसलिए मैं ऐसा नहीं कर सकता। अगर एल्म के प्रकार अन्य कार्यात्मक भाषाओं की तरह कुछ भी काम करते हैं, तो मैं वास्तव में विभिन्न कार्यों से मूल्यों की रचना कर सकता हूं जैसे कि मुझे पता है कि वे त्रुटियां हैं या नहीं! यह एफपी भाषाओं की खासियत है।

— एंड्रेस एफ।

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

— एंड्रेस एफ।

@ अगर आप इस सब से एक चीज लेना चाहते हैं, तो इसे एक लें: हमेशा सुनिश्चित करें कि आप ब्लूब पैराडॉक्स के शिकार न हों । नए वाक्य-विन्यास पर चिढ़ न हों। हो सकता है कि शक्तिशाली विशेषताओं के कारण आप वहां अपरिचित हों :)

— Andres F.

Answer 2

इस कथन को समझने के लिए, हमें पहले यह समझना होगा कि एक स्थिर प्रकार की प्रणाली हमें क्या खरीदती है। संक्षेप में, एक स्थिर प्रकार प्रणाली हमें क्या देती है, इसकी गारंटी है: यदि प्रोग्राम प्रकार की जाँच करता है, तो रनटाइम व्यवहारों की एक निश्चित श्रेणी उत्पन्न नहीं हो सकती है।

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

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

विभिन्न प्रकार की प्रणालियों के बीच का अंतर मूल रूप से है, जिसमें कितने, और कितने जटिल क्रम व्यवहार हैं जो वे नहीं होने के लिए साबित हो सकते हैं। कमजोर प्रकार के सिस्टम जैसे कि जावा केवल बहुत ही बुनियादी चीजों को साबित कर सकते हैं। उदाहरण के लिए, जावा यह साबित कर सकता है कि टाइप की जाने वाली विधि Stringवापस नहीं लौट सकती List। लेकिन, उदाहरण के लिए, यह साबित नहीं हो सकता है कि विधि वापस नहीं आएगी। यह भी साबित नहीं हो सकता है कि विधि एक अपवाद नहीं फेंकेगी। और यह साबित नहीं कर सकता कि यह गलत नहीं लौटेगा String - कोई भी Stringटाइप चेकर को संतुष्ट करेगा। (और, निश्चित रूप से, यहां तक ​​कि nullइसे भी संतुष्ट करेगा।) बहुत सरल चीजें हैं जो जावा साबित नहीं कर सकती हैं, यही कारण है कि हमारे पास अपवाद हैं ArrayStoreException, जैसे कि ClassCastException, या हर किसी का पसंदीदा NullPointerException,।

एजडा की अधिक शक्तिशाली प्रकार की प्रणालियां "दो तर्कों का योग लौटाएगी" या "एक तर्क के रूप में पारित सूची के क्रमबद्ध संस्करण" जैसी चीजें भी साबित कर सकती हैं।

अब, एल्म के डिजाइनरों के इस कथन से क्या अभिप्राय है कि उनके पास कोई रनटाइम अपवाद नहीं है, एल्म के प्रकार की प्रणाली अनुपस्थिति (रनटाइम व्यवहार) का एक महत्वपूर्ण हिस्सा साबित हो सकती है कि अन्य भाषाओं में ऐसा नहीं होने के लिए साबित नहीं किया जा सकता है और इस प्रकार नेतृत्व हो सकता है रनटाइम पर गलत व्यवहार करने के लिए (जिसका सबसे अच्छा मामले में एक अपवाद है, एक बदतर स्थिति में एक दुर्घटना का मतलब है, और सभी के सबसे बुरे मामले में कोई दुर्घटना नहीं, कोई अपवाद नहीं है, और बस एक चुपचाप गलत परिणाम है)।

इसलिए, वे यह नहीं कह रहे हैं कि "हम अपवादों को लागू नहीं करते हैं"। वे कह रहे हैं "ऐसी चीजें जो विशिष्ट भाषाओं में क्रमिक अपवाद होंगी जो कि एल्म में आने वाले विशिष्ट प्रोग्रामर के पास अनुभव के साथ होती हैं, उन्हें टाइप सिस्टम द्वारा पकड़ा जाता है"। बेशक, इदरीस, एजडा, गुरु, एपिग्राम, इसाबेल / एचओएल, कोक या इसी तरह की भाषाओं से आने वाले किसी व्यक्ति को एल्म की तुलना में बहुत कमजोर दिखाई देगा। यह कथन विशिष्ट जावा, C♯, C ++, ऑब्जेक्टिव-सी, PHP, ECMAScript, पायथन, रूबी, पर्ल,… प्रोग्रामर पर अधिक लक्षित है।

Comments

संभावित संपादकों पर ध्यान दें: मुझे दोहरे और यहां तक ​​कि ट्रिपल नकारात्मक के उपयोग के बारे में बहुत खेद है। हालांकि, मैंने उन्हें उद्देश्य पर छोड़ दिया: टाइप सिस्टम कुछ प्रकार के रनटाइम व्यवहारों की अनुपस्थिति की गारंटी देते हैं, अर्थात वे कुछ चीजों को नहीं होने की गारंटी देते हैं। और मैं उस सूत्रीकरण को "अक्षुण्ण नहीं साबित करना चाहता था" बरकरार रखना चाहता था, जो दुर्भाग्य से निर्माण की ओर ले जाता है जैसे "यह साबित नहीं कर सकता कि कोई विधि वापस नहीं आएगी"। यदि आप इन्हें सुधारने का कोई रास्ता खोज सकते हैं, तो आगे बढ़ें, लेकिन कृपया उपरोक्त को ध्यान में रखें। धन्यवाद!

— जोर्ग डब्ल्यू मित्तग

कुल मिलाकर अच्छा उत्तर, लेकिन एक छोटा सा निप्पिक: "एक प्रकार का चेकर एक प्रमेय कहावत के समान है।" दरअसल, एक प्रकार का चेकर एक प्रमेय चेकर के समान अधिक है: वे दोनों सत्यापन करते हैं , कटौती नहीं ।

— गार्डेनहेड

Answer 3

एल्म बिना किसी रनटाइम अपवाद की गारंटी दे सकता है इसी कारण से सी बिना रनटाइम अपवाद की गारंटी नहीं दे सकता है: भाषा अपवादों की अवधारणा का समर्थन नहीं करती है।

एल्म में रनटाइम के दौरान त्रुटि की स्थिति का संकेत होता है, लेकिन यह प्रणाली अपवाद नहीं है, यह "परिणाम" है। एक फ़ंक्शन जो विफल हो सकता है एक "परिणाम" देता है जिसमें या तो एक नियमित मूल्य या एक त्रुटि होती है। एल्म्स दृढ़ता से टाइप किया जाता है, इसलिए यह टाइप सिस्टम में स्पष्ट है। यदि कोई फ़ंक्शन हमेशा पूर्णांक लौटाता है, तो इसका प्रकार होता है Int। लेकिन अगर यह या तो पूर्णांक देता है या विफल रहता है, तो रिटर्न प्रकार है Result Error Int। (स्ट्रिंग त्रुटि संदेश है।) यह आपको कॉल साइट पर दोनों मामलों को स्पष्ट रूप से संभालने के लिए मजबूर करता है।

यहाँ एक उदाहरण है (थोड़ा सरलीकृत) से:

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

toIntइनपुट विफल होने पर फ़ंक्शन विफल हो सकता है, इसलिए इसका रिटर्न प्रकार है Result String int। वास्तविक पूर्णांक मान प्राप्त करने के लिए, आपको पैटर्न मिलान के माध्यम से "अनपैक" करना होगा, जो बदले में आपको दोनों मामलों को संभालने के लिए मजबूर करता है।

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

Comments

@ यहाँ एक उदाहरण है। भाषा की कल्पना करें A अपवादों की अनुमति देता है। फिर आपको फंक्शन दिया जाता है doSomeStuff(x: Int): Int। आम तौर पर आप इसे वापस करने की उम्मीद करते हैं Int, लेकिन क्या यह एक अपवाद भी फेंक सकता है? इसके स्रोत कोड को देखे बिना, आप नहीं जान सकते। इसके विपरीत, एक भाषा B जो टाइप के माध्यम से त्रुटियों को एनकोड करती है, हो सकता है कि एक ही फ़ंक्शन इस तरह घोषित हो: doSomeStuff(x: Int): ErrorOrResultOfType<Int>(एल्म में यह प्रकार वास्तव में नाम है Result)। पहले मामले के विपरीत, यह अब तुरंत स्पष्ट है कि क्या फ़ंक्शन विफल हो सकता है, और आपको इसे स्पष्ट रूप से संभालना होगा।

— एंड्रेस एफ।

जैसा कि @RobertHarvey एक अन्य उत्तर पर एक टिप्पणी में निहित है, यह मूल रूप से जावा में चेक किए गए अपवादों की तरह लगता है। मैंने शुरुआती दिनों में जावा के साथ काम करना सीखा था जब अधिकांश अपवादों की जाँच की गई थी कि आप वास्तव में कोड को लिखने के लिए मजबूर नहीं होना चाहते हैं क्योंकि वे उस बिंदु पर त्रुटियों के लिए हमेशा लिखते हैं।

— जिमीजैम

@JimmyJames यह अपवाद नहीं है क्योंकि अपवाद की जाँच नहीं की जाती है, पर ध्यान नहीं दिया जा सकता ("निगल लिया") और प्रथम श्रेणी के मान नहीं हैं :) मैं वास्तव में इसे समझने के लिए एक सांख्यिकीय रूप से टाइप की गई कार्यात्मक भाषा सीखने की सलाह देता हूं। यह कुछ नई बात नहीं है, एल्म ने बनाया - यह है कि आप एमएल या हास्केल जैसी भाषाओं में कैसे प्रोग्राम करते हैं, और यह जावा से अलग है।

— एंड्रेस एफ।

@AndresF। this is how you program in languages such as ML or Haskellहास्केल में, हाँ; एमएल, नहीं। रॉबर्ट हार्पर, मानक एमएल और प्रोग्रामिंग भाषा शोधकर्ता के लिए एक प्रमुख योगदानकर्ता, अपवादों को उपयोगी मानते हैं । त्रुटि प्रकार उन मामलों में फ़ंक्शन संरचना के तरीके से मिल सकते हैं जहां आप गारंटी दे सकते हैं कि त्रुटि नहीं होगी। अपवादों का प्रदर्शन भी अलग होता है। आप उन अपवादों के लिए भुगतान नहीं करते हैं जिन्हें फेंका नहीं गया है, लेकिन आप हर बार त्रुटि मानों की जांच के लिए भुगतान करते हैं, और अपवाद कुछ एल्गोरिदम में बैकट्रैकिंग को व्यक्त करने का एक स्वाभाविक तरीका है

— डोभाल

@JimmyJames उम्मीद है कि अब आप देखेंगे कि जाँच किए गए अपवाद और वास्तविक त्रुटि प्रकार केवल सतही रूप से समान हैं। जाँच किए गए अपवादों को इनायत से जोड़ नहीं है, उपयोग करने के लिए बोझिल हैं, और अभिव्यक्ति उन्मुख नहीं हैं (और इसलिए आप उन्हें बस "निगल" सकते हैं, जैसे कि यह जावा के साथ होता है)। अनियंत्रित अपवाद कम बोझिल हैं, यही कारण है कि वे हर जगह जावा में आदर्श हैं, लेकिन वे आपके ऊपर यात्रा करने की अधिक संभावना रखते हैं, और आप एक फ़ंक्शन घोषणा को देखकर नहीं बता सकते हैं कि यह फेंकता है या नहीं, आपके कार्यक्रम को कठिन बना देता है। समझने के लिए।

— एंड्रेस एफ।

Answer 4

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

इस प्रश्न की व्याख्या किसी भी तरह से की जा सकती है, लेकिन चूंकि आपने एल्म का उल्लेख टिप्पणियों में किया है, इसलिए संदर्भ स्पष्ट है।

एल्म अन्य बातों के अलावा, एक सांख्यिकीय रूप से टाइप की गई प्रोग्रामिंग भाषा है। इस प्रकार की प्रणालियों के लाभों में से एक यह है कि त्रुटियों के कई वर्ग (हालांकि सभी नहीं) कंपाइलर द्वारा पकड़े जाते हैं, इससे पहले कि प्रोग्राम वास्तव में उपयोग किया जाता है। कुछ प्रकार की त्रुटियों को अपवाद के रूप में फेंके जाने के बजाय (जैसे एल्म के ) Resultऔर प्रकारों में एन्कोड किया जा सकता Taskहै। एल्म के डिजाइनरों का यही मतलब है: कई त्रुटियों को "रन टाइम" के बजाय संकलन समय पर पकड़ा जाएगा, और संकलक आपको उन्हें अनदेखा करने और सर्वश्रेष्ठ की उम्मीद करने के बजाय उनसे निपटने के लिए मजबूर करेगा। यह स्पष्ट है कि यह एक फायदा क्यों है: बेहतर है कि प्रोग्रामर उपयोगकर्ता को समस्या से पहले ही अवगत करा देता है।

ध्यान दें कि जब आप अपवादों का उपयोग नहीं करते हैं, तो त्रुटियों को अन्य, कम आश्चर्यजनक तरीकों से एन्कोड किया जाता है। से एल्म के प्रलेखन :

एल्म की गारंटी में से एक यह है कि आप अभ्यास में रनटाइम त्रुटियों को नहीं देखेंगे। NoRedInk उत्पादन में एल्म का उपयोग लगभग एक साल से कर रहा है, और उनके पास अभी भी एक नहीं है! एल्म में सभी गारंटी की तरह, यह मौलिक भाषा डिजाइन विकल्पों के लिए नीचे आता है। इस मामले में, हमें इस तथ्य से मदद मिलती है कि एल्म त्रुटियों को डेटा के रूप में मानता है। (क्या आपने देखा है कि हम चीजों को डेटा यहाँ बहुत बनाते हैं?)

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

Comments

क्या मैं इसे गलत बता रहा हूं, या वे सिर्फ एक शब्दार्थ खेल खेल रहे हैं? उन्होंने "रन टाइम अपवाद" नाम को घोषित किया, लेकिन फिर इसे एक अलग तंत्र के साथ बदल दिया जो स्टैक तक त्रुटि जानकारी को बताता है। यह एक समान अवधारणा या ऑब्जेक्ट के अपवाद के कार्यान्वयन को बदलने जैसा लगता है जो त्रुटि संदेश को अलग तरीके से लागू करता है। यह शायद ही पृथ्वी-बिखर रहा है। यह किसी भी स्टेटिकल टाइप की गई भाषा की तरह है। COM HRESULT से .NET अपवाद पर स्विच करने की तुलना करें। विभिन्न तंत्र, लेकिन फिर भी एक रन टाइम अपवाद है, इससे कोई फर्क नहीं पड़ता कि आप इसे कहते हैं।

— माइक

@ माय ईमानदार होने के लिए मैंने एल्म को विस्तार से नहीं देखा। डॉक्स द्वारा देखते हुए, उनके पास प्रकार होते हैं Resultऔर Taskजो बहुत अधिक परिचित Eitherऔर Futureअन्य भाषाओं से मिलते-जुलते दिखते हैं। अपवादों के विपरीत, इन प्रकारों के मूल्यों को जोड़ा जा सकता है और कुछ बिंदु पर आपको उन्हें स्पष्ट रूप से संभालना चाहिए: क्या वे वैध मूल्य या त्रुटि का प्रतिनिधित्व करते हैं? मैं मन नहीं पढ़ता हूं, लेकिन प्रोग्रामर को आश्चर्यचकित करने की कमी यह है कि शायद एल्म डिजाइनरों का मतलब "नो रन टाइम अपवाद" है :)

— एंड्रेस एफ।

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

— एंड्रेस एफ।

आपकी टिप्पणियों के अनुसार मुझे लगता है कि इसमें "स्थिर प्रकार की जाँच" से अधिक है। आप इसे टाइपस्क्रिप्ट का उपयोग करके जेएस में जोड़ सकते हैं, जो एक नए "मेक-या-ब्रेक" पारिस्थितिकी तंत्र की तुलना में बहुत कम बाधा है।

— atoth

@AndresF।: तकनीकी रूप से, जावा की प्रकार प्रणाली की सबसे नई विशेषता पैरामीट्रिक पोलिमोर्फ़िज्म है, जो 60 के दशक के अंत में बनती है। इसलिए, एक तरीके से बोलना, "आधुनिक" कहना जब आपका मतलब है "जावा नहीं" कुछ हद तक सही है।

— जर्ग डब्ल्यू मित्तग

Answer 5

एल्म का दावा:

अभ्यास में कोई रनटाइम त्रुटियाँ नहीं । कोई अशक्त नहीं। कोई अपरिभाषित कोई फ़ंक्शन नहीं है।

लेकिन आप रनटाइम अपवादों के बारे में पूछते हैं । एक अंतर है।

एल्म में, कुछ भी अप्रत्याशित परिणाम नहीं देता है। आप एल्म में एक वैध कार्यक्रम नहीं लिख सकते हैं जो रनटाइम त्रुटियों का उत्पादन करता है। इस प्रकार, आपको अपवादों की आवश्यकता नहीं है।

तो, सवाल यह होना चाहिए:

"कोई रनटाइम त्रुटियों" होने का क्या लाभ है?

यदि आप कोड लिख सकते हैं जिसमें कभी भी रनटाइम त्रुटियाँ नहीं हैं, तो आपके प्रोग्राम कभी भी क्रैश नहीं होंगे।