Typescript: सुझाव: 'थ्रो' क्लॉज और टाइप किया हुआ कैच क्लॉज

बस स्पष्ट करने के लिए - यहां एक विचार उपयोगकर्ताओं को अपवाद पकड़ने के लिए मजबूर नहीं करना है, बल्कि कैच क्लॉज वैरिएबल के प्रकार का बेहतर अनुमान लगाने के लिए है?

@DanielRosenwasser
हां, उपयोगकर्ताओं को अपवादों को पकड़ने के लिए मजबूर नहीं किया जाएगा, इसलिए यह संकलक के साथ ठीक है (रनटाइम पर त्रुटि निश्चित रूप से फेंक दी जाती है):

function fn() {
    throw "error";
}

fn();

// and
try {
    fn();
} finally {
    // do something here
}

लेकिन यह डेवलपर्स को यह व्यक्त करने का एक तरीका देगा कि कौन से अपवादों को फेंक दिया जा सकता है (अन्य पुस्तकालयों का उपयोग करते समय .d.ts फाइलों का उपयोग करना बहुत अच्छा होगा) और फिर कंपाइलर प्रकार को अपवाद प्रकारों को पकड़ खंड के अंदर रखें।

चेक किया हुआ थ्रो Tried<Result, Error> से किस प्रकार भिन्न है?

type Tried<Result, Error> = Success<Result> | Failure<Error>;
interface Success<Result> { kind: 'result', result: Result } 
interface Failure<Error> { kind: 'failure', error: Error }
function isSuccess(tried: Tried<Result, Error>): tried is Success<Result> {
   return tried.kind === 'result';
}
function mightFail(): Tried<number, string> {
}
const tried = mightFail();
if (isSuccess(tried)) {
    console.log(tried.success);
}  else {
    console.error(tried.error);
}

के बजाए

try {
    const result: Result = mightFail();
    console.log(success);
} catch (error: Error) {
    console.error(error);
}

@ अलेक्सी-बायकोव

आप सुझाव दे रहे हैं कि मेरे कोड में बिल्कुल भी throw का उपयोग न करें और इसके बजाय परिणामों को लपेटें (उन कार्यों में जो त्रुटि हो सकती है)।
इस दृष्टिकोण में कुछ कमियां हैं:

• यह रैपिंग अधिक कोड बनाता है
• इसके लिए आवश्यक है कि इनवॉइस किए गए फ़ंक्शन की सभी श्रृंखला इस लिपटे हुए मान (या त्रुटि) को वापस कर दें या वैकल्पिक रूप से Tried<> प्राप्त करने वाला फ़ंक्शन त्रुटि को अनदेखा करने का विकल्प नहीं चुन सकता है।
• यह एक मानक, तृतीय पक्ष पुस्तकालय नहीं है और देशी जेएस त्रुटियों को फेंक देता है

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

एक SyntaxError अपवाद फेंकता है यदि पार्स करने के लिए स्ट्रिंग मान्य JSON नहीं है

और यह एक अच्छा मामला है जब त्रुटि का दस्तावेजीकरण किया जाता है।

और यह एक अच्छा मामला है जब त्रुटि का दस्तावेजीकरण किया जाता है।

त्रुटि से सिंटैक्स त्रुटि को अलग करने के लिए जावास्क्रिप्ट में कोई विश्वसनीय तरीका है?

• हां, यह अधिक कोड है, लेकिन चूंकि किसी वस्तु में एक खराब स्थिति का प्रतिनिधित्व किया जाता है, इसलिए इसे किसी अन्य मूल्य की तरह ही एक वैध परिणाम में संसाधित, त्याग, संग्रहीत या परिवर्तित करने के लिए पारित किया जा सकता है

• आप कोशिश की गई वापसी की कोशिश को भी अनदेखा कर सकते हैं, कोशिश की गई को एक मोनैड के रूप में देखा जा सकता है, मोनैडिक कंप्यूटेशंस की तलाश करें

  function mightFail(): Tried<number, string> {
  }
  function mightFailToo(): Tried<number, string> {
      const tried = mightFail();
      if (isSuccess(tried))  { 
           return successFrom(tried.result * 2);
      } else {
           return tried;
      }
  }
  

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

• जावास्क्रिप्ट रनटाइम से चेक किए गए अपवादों के लिए कोई समर्थन नहीं है, और मुझे डर है कि इसे अकेले टाइपस्क्रिप्ट में लागू नहीं किया जा सकता है

इसके अलावा एक विशेष परिणाम मामले के रूप में एक अपवाद को कूटबद्ध करना FP दुनिया में एक बहुत ही सामान्य प्रथा है

एक संभावित परिणाम को 2 भागों में विभाजित करते हुए:

• एक रिटर्न स्टेटमेंट द्वारा दिया गया और
• एक और थ्रो द्वारा दिया गया

एक बनी हुई कठिनाई दिखती है

मेरी राय में, थ्रो तेजी से और जोर से विफल होने के लिए अच्छा है जब आप इसके बारे में कुछ नहीं कर सकते हैं, स्पष्ट रूप से कोडित परिणाम किसी भी चीज के लिए अच्छे हैं जो एक खराब लेकिन अपेक्षित स्थिति का तात्पर्य है जिससे आप पुनर्प्राप्त कर सकते हैं

विचार करना:

// throw/catch
declare function doThis(): number throws string;
declare function doThat(): number throws string;
function doSomething(): number throws string {
    let oneResult: number | undefined = undefined;
    try {
        oneResult = doThis();
    } catch (e) {
        throw e;
    }

    let anotherResult: number | undefined = undefined;
    try {
        anotherResult = doThat();
    } catch (e) {
        throw e;
    }
    return oneResult + anotherResult;
}

// explicit results
declare function doThis(): Tried<number, string>;
declare function doThat(): Tried<number, string>;
function withBothTried<T, E, R>(one: Tried<T, E>, another: Tried<T, E>, haveBoth: (one: T, another: T) => R): Tried<T, R> {
    return isSuccess(one)
        ? isSuccess(another)
            ? successFrom(haveBoth(one.result, another.result))
            : another
        : one;
}
function add(one: number, another: number) { return one + another; }
function doSomething(): Tried<number, string> {
    return withBothTried(
        doThis(),
        doThat(),
        add
    );
}

@ अलेक्सी-बायकोव

JSON.parse SyntaxError सकता है कि मुझे दस्तावेज़ों में फ़ंक्शन को केवल यह जानने के लिए देखना होगा कि यह फेंक सकता है, और यह देखना आसान होगा कि .d.ts में
और हाँ, आप जान सकते हैं कि यह SyntaxError का उपयोग करके instanceof है।

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

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

मैं आपसे असहमत हूं, कई मामलों में आप फेंकी गई त्रुटियों से उबर सकते हैं, और यदि भाषा आपको इसे बेहतर तरीके से व्यक्त करने देती है तो ऐसा करना आसान हो जाएगा।

टाइपस्क्रिप्ट में बहुत सी चीजों की तरह, जावास्क्रिप्ट में फीचर के समर्थन की कमी कोई समस्या नहीं है।
इस:

try {
    mightFail();
} catch (e: MyError | string) {
    if (e instanceof MyError) { ... }
    else if (typeof e === "string") { ... }
    else {}
}

जावास्क्रिप्ट में अपेक्षित रूप से काम करेगा, बिना टाइप एनोटेशन के।

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

अगर हम ब्राउज़र के बारे में बात कर रहे हैं तो instanceof केवल उसी विंडो/दस्तावेज़ से निकलने वाली सामग्री के लिए अच्छा है, इसे आज़माएं:

var child = window.open('about:blank');
console.log(child.Error === window.Error);

तो जब आप करते हैं:

try { child.doSomething(); } catch (e) { if (e instanceof SyntaxError) { } }

आप इसे नहीं पकड़ेंगे

अपवादों के साथ एक और समस्या है कि वे आपके कोड में उस स्थान से बहुत आगे निकल सकते हैं जहाँ आप उनसे होने की उम्मीद करते हैं

try {
   doSomething(); // <-- uses 3rd party library that by coincidence throws SyntaxError too, but you don' t know it 
} catch (e) {}

इसके अलावा instanceof प्रोटोटाइप विरासत के लिए कमजोर है, इसलिए आपको हमेशा अंतिम पूर्वज के खिलाफ जांच करने के लिए अतिरिक्त सावधानी बरतने की आवश्यकता है

class StandardError {}
class CustomError extends StandardError {
}
function doSomething() { throw new CustomError(); }
function oldCode() {
   try {
      doSomething();
   } catch (e) {
      if (e instanceof StandardError) {
          // problem
      }
   }
}

@ alexey-bykov स्पष्ट रूप से त्रुटियों को फैलाने जैसा कि आप मोनैडिक संरचनाओं में सुझाव देते हैं, काफी कठिन और कठिन काम है। यह बहुत प्रयास करता है, कोड को समझने में कठिन बनाता है और सहने योग्य होने के किनारे पर होने के लिए भाषा समर्थन / प्रकार-संचालित उत्सर्जन की आवश्यकता होती है। यह किसी ऐसे व्यक्ति की टिप्पणी है जो हास्केल और एफपी को समग्र रूप से लोकप्रिय बनाने में बहुत प्रयास करता है।

यह विशेष रूप से उत्साही लोगों (स्वयं शामिल) के लिए एक कामकाजी विकल्प है, हालांकि मुझे नहीं लगता कि यह बड़े दर्शकों के लिए एक व्यवहार्य विकल्प है।

दरअसल, यहां मेरी मुख्य चिंता यह है कि लोग एरर को सबक्लास करना शुरू कर देंगे। मुझे लगता है कि यह एक भयानक पैटर्न है। अधिक आम तौर पर, कुछ भी जो इंस्टोफ ऑपरेटर के उपयोग को बढ़ावा देता है, वह कक्षाओं के आसपास अतिरिक्त भ्रम पैदा करने वाला है।

यह किसी ऐसे व्यक्ति की टिप्पणी है जो हास्केल और एफपी को समग्र रूप से लोकप्रिय बनाने में बहुत प्रयास करता है।

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

और यह उतना कठिन नहीं है जितना आप सोचते हैं, बशर्ते सभी संयोजक पहले से ही लिखे गए हों, बस उनका उपयोग डेटा प्रवाह बनाने के लिए करें, जैसा कि हम अपने प्रोजेक्ट में करते हैं, लेकिन मैं मानता हूं कि TS इसका बेहतर समर्थन कर सकता था: #2319

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

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

ओपी प्रश्न पर वापस - instanceof उपयोग करने के लिए एक खतरनाक ऑपरेटर है। हालांकि स्पष्ट अपवाद Error तक सीमित नहीं हैं। आप अपने स्वयं के एडीटी या कस्टम पीओजेओ त्रुटियों को भी फेंक सकते हैं। प्रस्तावित सुविधा काफी उपयोगी हो सकती है और निश्चित रूप से, इसका दुरुपयोग भी बहुत मुश्किल से किया जा सकता है। किसी भी मामले में यह कार्यों को अधिक पारदर्शी बनाता है जो निस्संदेह एक अच्छी बात है। कुल मिलाकर मैं इस पर 50/50 का हूं :)

@ अलेक्सी-बायकोव

डेवलपर्स को आपके द्वारा वर्णित विभिन्न जेएस मुद्दों के बारे में पता होना चाहिए, टाइपस्क्रिप्ट में throws जोड़ने के बाद जेएस के लिए कुछ भी नया परिचय नहीं है, यह केवल टाइपस्क्रिप्ट को मौजूदा जेएस व्यवहार को व्यक्त करने की क्षमता के रूप में भाषा के रूप में देता है।

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

@aluanhaddad
Error का विस्तार करना एक भयानक पैटर्न क्यों है?

@gcnew
instanceof के लिए, यह सिर्फ एक उदाहरण था, मैं हमेशा नियमित वस्तुओं को फेंक सकता हूं जिनमें विभिन्न प्रकार होते हैं और फिर उनके बीच अंतर करने के लिए टाइप गार्ड का उपयोग करते हैं।
यह तय करने के लिए डेवलपर पर निर्भर होगा कि वह किस प्रकार की त्रुटियों को फेंकना चाहता है, और शायद यह मामला पहले से ही है, लेकिन वर्तमान में इसे व्यक्त करने का कोई तरीका नहीं है, जिसे यह सुझाव हल करना चाहता है।

@nitzantomer मूल वर्गों को उपवर्गित करना ( Error , Array , RegExp , आदि) पुराने ECMAScript संस्करणों (ES6 से पहले) में समर्थित नहीं था। इन वर्गों के लिए निम्न स्तर का उत्सर्जन अप्रत्याशित परिणाम देता है (सर्वश्रेष्ठ प्रयास किया जाता है लेकिन यह जहाँ तक जा सकता है) और दैनिक आधार पर कई मुद्दों को लॉग इन करने का कारण है। एक नियम के रूप में - जब तक आप हाल के ईसीएमएस्क्रिप्ट संस्करणों को लक्षित नहीं कर रहे हैं और वास्तव में जानते हैं कि आप क्या कर रहे हैं, तब तक मूल निवासी उप-वर्ग न करें।

@gcnew
ओह, मैं इसके बारे में अच्छी तरह जानता हूं क्योंकि मैंने कुछ घंटों से अधिक समय यह पता लगाने में लगाया कि क्या गलत हुआ।
लेकिन अब ऐसा करने की क्षमता के साथ ऐसा नहीं करने का कोई कारण नहीं होना चाहिए (ES6 को लक्षित करते समय)।

किसी भी मामले में यह सुझाव यह नहीं मानता कि उपयोगकर्ता त्रुटि वर्ग को उप-वर्गीकृत कर रहा है, यह केवल एक उदाहरण था।

@nitzantomer मैं यह तर्क नहीं दे रहा हूं कि सुझाव Error तक सीमित है। मैंने अभी समझाया कि इसे उप-वर्ग करने के लिए यह एक खराब पैटर्न क्यों है। अपनी पोस्ट में मैंने वास्तव में इस रुख का बचाव किया कि कस्टम ऑब्जेक्ट्स या भेदभाव वाले यूनियनों का भी इस्तेमाल किया जा सकता है।

instanceof खतरनाक है और इसे एक विरोधी पैटर्न माना जाता है, भले ही आप जावास्क्रिप्ट की विशिष्टताओं को हटा दें - उदाहरण के लिए इंस्टोफ ऑपरेटर से सावधान रहें । इसका कारण यह है कि कंपाइलर नए उपवर्गों द्वारा पेश किए गए बग से आपकी रक्षा नहीं कर सकता है। instanceof का उपयोग करने वाला तर्क नाजुक है और खुले/बंद सिद्धांत का पालन नहीं करता है, क्योंकि यह केवल कुछ मुट्ठी भर विकल्पों की अपेक्षा करता है। यहां तक ​​कि अगर एक वाइल्डकार्ड केस जोड़ा जाता है, तो भी नए व्युत्पन्न में त्रुटियां होने की संभावना होती है क्योंकि वे लेखन के समय की गई धारणाओं को तोड़ सकते हैं।

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

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

@gcnew
इस तरह यह सी # में किया जाता है, समस्या यह है कि दस्तावेज़ टाइपस्क्रिप्ट में मानक नहीं हैं।
मुझे याद नहीं है कि मैं एक परिभाषा फ़ाइल में आया हूं जो अच्छी तरह से प्रलेखित है। अलग-अलग lib.d.ts फाइलों में टिप्पणियां होती हैं, लेकिन उनमें फेंकी गई त्रुटियां नहीं होती हैं (एक अपवाद के साथ: lib.es6.d.ts में throws में Date[Symbol.toPrimitive](hint: string) है)।

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

मैं मानता हूं कि त्रुटि प्रबंधन को लागू करना अच्छी बात नहीं है, लेकिन इस सुविधा के होने से बस और जानकारी जुड़ जाएगी जिसका उपयोग वे लोग कर सकते हैं जो चाहते हैं।
इसके साथ समस्या:

... विफलता का प्रतिनिधित्व करने के बेहतर और वर्तमान में अधिक सामान्य तरीके हैं

क्या ऐसा करने का कोई मानक तरीका नहीं है।
आप यूनियन रिटर्न का उपयोग कर सकते हैं, @ एलेक्सी-बायकोव Tried<> का उपयोग करेगा, और किसी अन्य तृतीय पक्ष लाइब्रेरी का डेवलपर कुछ पूरी तरह से अलग करेगा।
त्रुटियों को फेंकना भाषाओं में एक मानक है (जेएस, जावा, सी # ...) और चूंकि यह सिस्टम का हिस्सा है और वर्कअराउंड नहीं है, इसलिए इसे (मेरी राय में) टाइपस्क्रिप्ट में बेहतर संचालन करना चाहिए, और इसका प्रमाण संख्या है मैंने यहां समय के साथ जिन मुद्दों को देखा है, उनमें से catch क्लॉज में टाइप एनोटेशन के लिए कहते हैं।

यदि कोई फ़ंक्शन (या फ़ंक्शन कहा जाता है) फेंक सकता है तो मुझे वीएस में टूलटिप में जानकारी प्राप्त करना अच्छा लगेगा। *.d.ts फ़ाइलों के लिए हमें शायद TS2.0 के बाद से इस तरह के नकली पैरामीटर की आवश्यकता है।

@HolgerJeromin
इसकी आवश्यकता क्यों होगी?

यहां एक सरल प्रश्न है, नीचे दिए गए कोड में dontCare के लिए कौन सा हस्ताक्षर अनुमान लगाया जाना चाहिए?

function mightThrow(): void throws string {
   if (Math.random() > 0.5) {
       throw 'hey!';
   }
}

function dontCare() {
   return mightThrow();
}

आपने अपने प्रस्ताव में जो कहा है उसके अनुसार यह होना चाहिए

function dontCare(): void throws string {

मैं कहता हूं कि यह एक प्रकार की त्रुटि होनी चाहिए क्योंकि चेक किए गए अपवाद को ठीक से नियंत्रित नहीं किया गया था

function dontCare() { // <-- Checked exception wasn't handled.
         ^^^^^^^^^^

ऐसा क्यों है?

क्योंकि अन्यथा तत्काल कॉल करने वाले की स्थिति भ्रष्ट होने की बहुत अच्छी संभावना है:

class MyClass {
    private values: number[] = [];

    keepAllValues(values: number[]) {
       for (let index = 0; index < values.length; index ++) {
            this.values.push(values[index]); 
            mightThrow();
       }
    }
}

यदि आप एक अपवाद को अपने माध्यम से फिसलने देते हैं, तो आप इसे जाँच के रूप में अनुमान नहीं लगा सकते हैं, क्योंकि keepAllValues के व्यवहार अनुबंध का इस तरह से उल्लंघन किया जाएगा (मूल इरादे के बावजूद सभी मूल्यों को नहीं रखा गया था)

उन्हें तुरंत पकड़ने और उन्हें स्पष्ट रूप से फिर से फेंकने का एकमात्र सुरक्षित तरीका है

    keepAllValues(values: number[]) {
           for (let index = 0; index < values.length; index ++) {
                this.values.push(values[index]); 
                try {
                    mightThrow();
                } catch (e) {
                    // the state of MyClass is going to be corrupt anyway
                    // but unlike the other example this is a deliberate choice
                    throw e;
                }
           }
    }

अन्यथा कॉल करने वालों को पता है कि क्या ट्रोन किया जा सकता है, आप उन्हें गारंटी नहीं दे सकते कि कोड का उपयोग करके आगे बढ़ना सुरक्षित है जो अभी फेंक दिया गया है

इसलिए स्वचालित जाँच अपवाद अनुबंध प्रसार जैसी कोई चीज़ नहीं है

और अगर मैं गलत हूं तो मुझे सुधारें, यह वही है जो जावा करता है, जिसका आपने पहले एक उदाहरण के रूप में उल्लेख किया था

@ अलेक्सी-बायकोव
इस:

function mightThrow(): void {
   if (Math.random() > 0.5) {
       throw 'hey!';
   }
}

function dontCare() {
   return mightThrow();
}

इसका मतलब है कि mightThrow और dontCare दोनों का अनुमान throws string है, हालांकि:

function dontCare() {
    try {
        return mightThrow();
    } catch (e: string) {
        // do something
    }
}

throw क्लॉज नहीं होगा क्योंकि त्रुटि को संभाला गया था।
इस:

function mightThrow(): void throws string | MyErrorType { ... }

function dontCare() {
    try {
        return mightThrow();
    } catch (e: string | MyErrorType) {
        if (typeof e === "string") {
            // do something
        } else { throw e }
    }
}

throws MyErrorType होगा।

आपके keepAllValues उदाहरण के लिए, मुझे यकीन नहीं है कि आपका क्या मतलब है, आपके उदाहरण में:

class MyClass {
    private values: number[] = [];

    keepAllValues(values: number[]) {
       for (let index = 0; index < values.length; index ++) {
            this.values.push(values[index]); 
            mightThrow();
       }
    }
}

MyClass.keepAllValues का अनुमान throws string के रूप में लगाया जाएगा क्योंकि mightThrow एक string फेंक सकता है और उस त्रुटि को नियंत्रित नहीं किया गया था।

जहां तक ​​आपके keepAllValues उदाहरण का सवाल है, मुझे नहीं पता कि आपका क्या मतलब है

मेरा मतलब था कि अपवाद mightThrow keepAllValues करते हैं और इसे अपने राज्य को भ्रष्ट छोड़कर जो कुछ भी कर रहे थे उसके बीच में इसे खत्म कर देते हैं। यह एक समस्या है। आपका सुझाव है कि इस समस्या पर अपनी आँखें बंद कर लें और दिखावा करें कि यह गंभीर नहीं है। मैं जो सुझाव देता हूं वह यह है कि इस समस्या को हल करने की आवश्यकता है कि सभी चेक किए गए अपवादों को तुरंत नियंत्रित किया जाए और स्पष्ट रूप से पुनर्स्थापित किया जाए। इस तरह राज्य को अनजाने में भ्रष्ट करने का कोई रास्ता नहीं है। और यद्यपि यह अभी भी भ्रष्ट हो सकता है यदि आप ऐसा चुनते हैं, तो इसके लिए कुछ जानबूझकर कोडिंग की आवश्यकता होगी।

इसके बारे में सोचें, हम अपवादों के बारे में 2 तरीके अपना सकते हैं:

• उन्हें संभालना, जिससे दुर्घटना हो जाती है, यदि दुर्घटना वही है जो आप चाहते हैं तो हम यहाँ ठीक हैं
• यदि आप एक दुर्घटना नहीं चाहते हैं तो आपको कुछ मार्गदर्शन की आवश्यकता है कि आपको किस प्रकार के अपवाद की तलाश करनी है, और यह वह जगह है जहां आपका प्रस्ताव आता है: चेक किए गए अपवाद - सभी स्पष्ट रूप से सूचीबद्ध हैं, ताकि आप उन सभी को संभाल सकें और डॉन कुछ भी याद मत करो

अब अगर हमने चेक किए गए अपवादों के साथ जाने का फैसला किया है जो ठीक से संभाले जाते हैं और एक दुर्घटना को रोकते हैं तो हमें ऐसी स्थिति से बाहर निकलने की जरूरत है जब हम कई परतों से आने वाले अपवाद को संभालते हैं जहां आप इसे पकड़ रहे हैं:

export function calculateFormula(input) {
    return calculateSubFormula(input);
}
export function calculateSubFormula(input) {
   return calculateSubSubFormula(input);
}
export function calculateSubSubFormula(input): number throws DivisionByZero  {
   return 1/input;
}

try {
   calculateFormula(0);
} catch (e: DivisionByZero) {
   // it doesn't make sense to expose DivisionByZero from under several layers of calculations
   // to the top level where nothing we can do or even know what to do about it
   // basically we cannot recover from it, because it happened outside of our immediate reach that we can control
}

उपरोक्त उदाहरण विचार के लिए एक दिलचस्प मामला लाता है, इसका अनुमानित हस्ताक्षर क्या होगा:

function boom(value: number) /* what comes here?*/  {
    return 1/value;
}

एक और दिलचस्प मामला

// 1.
function run<R, E>(callback(): R throws E) /* what comes here? */ {
    try {
        return callback();
    } catch (e: DivisionByZero) {
        // ignore
    }
}

function throw() { return 1 / 0; }

// 2.
run(throw); /* what do we expect here? */

@ अलेक्सी-बायकोव
तो आप प्रस्ताव करते हैं कि सभी त्रुटियों को जावा के साथ संभाला जाना चाहिए?
मैं इसका प्रशंसक नहीं हूं (भले ही मैं जावा से आया हूं और अभी भी इसे प्यार करता हूं) क्योंकि जेएस/टीएस अधिक गतिशील हैं और उनके उपयोगकर्ता इसके आदी हैं।
यह एक ध्वज हो सकता है जो आपको त्रुटियों से निपटने में मदद करता है यदि आप इसे संकलित करते समय शामिल करते हैं (जैसे strictNullChecks )।

मेरा सुझाव यहां हैंडल न किए गए अपवादों को हल करने के लिए नहीं है, आपके द्वारा पोस्ट किया गया कोड अब इस सुविधा को लागू किए बिना टूट जाएगा, और यह जेएस में भी टूट जाएगा।
मेरा सुझाव सिर्फ आपको एक डेवलपर के रूप में विभिन्न त्रुटियों के बारे में अधिक जागरूक होने देता है जो कि फेंकी जा सकती हैं, यह अभी भी आप पर निर्भर है कि उन्हें संभालना है या उन्हें अनदेखा करना है।

0 अंक से विभाजन के लिए, इसके परिणामस्वरूप कोई त्रुटि नहीं होती है:

console.log(1 / 0) // Infinity
console.log(1 / "hey!") // NaN

फेंकी जा सकने वाली विभिन्न त्रुटियों के बारे में अधिक जागरूक

ऐसा करने का कोई मतलब नहीं है जब तक कि वे उनसे निपट नहीं सकते, मेरे द्वारा सूचीबद्ध मामलों के कारण वर्तमान प्रस्ताव व्यवहार्य नहीं है

तो आप प्रस्ताव करते हैं कि सभी त्रुटियों को जावा के साथ संभाला जाना चाहिए?

हाँ, इसका मतलब यह है कि अपवादों की जाँच की जा रही है

@ अलेक्सी-बायकोव
मुझे समझ नहीं आता कि आपके द्वारा सूचीबद्ध कोई भी मामला इस प्रस्ताव को अव्यवहार्य क्यों बना देता है।

किसी त्रुटि को संभालने में कोई समस्या नहीं है जिसे मंगलाचरण श्रृंखला के नीचे फेंक दिया गया था, भले ही मैं एक ऐसे फ़ंक्शन का उपयोग कर रहा हूं जो DivisionByZero फेंकने का अनुमान लगाया गया था (चाहे वह कहां फेंका गया हो), मैं इसे संभालना चुन सकता हूं .
मैं इसे विभिन्न तर्कों के साथ पुनः प्रयास करने का प्रयास कर सकता हूं, मैं उपयोगकर्ता को एक संदेश दिखा सकता हूं कि कुछ गलत हो गया है, मैं इस समस्या को लॉग कर सकता हूं ताकि मैं बाद में इसे संभालने के लिए अपना कोड बदल सकूं (यदि ऐसा अक्सर होता है)।

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

मैं देख रहा हूं कि आप क्या कह रहे हैं, जावास्क्रिप्ट रनटाइम पर कुछ भी नहीं बदला जा रहा है, हालांकि यहां आपका संदेश उपयोगकर्ताओं को कुछ भ्रम देना है कि वे जानते हैं कि वे एक अपवाद को संभालने के द्वारा क्या कर रहे हैं जो नीचे 20 परतों से नीचे उसी आत्मविश्वास के साथ आया था जैसा कि वे तत्काल अपवाद को संभाल लेंगे

नीचे 20 परतों में हुई समस्या को ठीक करने का कोई तरीका नहीं है

आप इसे लॉग कर सकते हैं, निश्चित रूप से, किसी भी अनियंत्रित अपवाद की तरह, लेकिन आप इसे ठीक नहीं कर सकते हैं

तो यह एक झूठ है जो आम तौर पर बोल रहा है, टीएस में पर्याप्त झूठ है, चलो लोगों को और भी भ्रमित न करें

@ अलेक्सी-बायकोव
आप जो वर्णन कर रहे हैं वह अपवादों का समर्थन करने वाली सभी भाषाओं में मौजूद है।
किसी ने नहीं कहा कि अपवाद को पकड़ने से समस्या ठीक हो जाएगी, लेकिन यह आपको इसे इनायत से संभालने देगा।

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

अभी डेवलपर्स यह नहीं जानते होंगे कि JSON.parse का उपयोग करने से त्रुटि हो सकती है, लेकिन अगर यह lib.d.ts का हिस्सा था और आईडीई उसे बताएगा (उदाहरण के लिए) तो शायद वह चुनना चाहेगा इस मामले को संभालो।

आप 20 परतों के नीचे हुई समस्या को इनायत से संभाल नहीं सकते, क्योंकि आंतरिक स्थिति 19 परतों में भ्रष्ट है और आप वहां नहीं जा सकते क्योंकि राज्य निजी है

रचनात्मक होने के लिए: मैं जो सुझाव दे रहा हूं वह यह है कि उपयोगकर्ताओं को तुरंत चेक किए गए अपवादों को संभालने और उन्हें स्पष्ट रूप से पुनर्स्थापित करने की आवश्यकता है, इस तरह हम अनपेक्षित भ्रम और अनियंत्रित से अलग चेक अपवादों को रद्द करते हैं:

• चेक अपवाद: तत्काल पहुंच में हुआ और इसे संभाला जाना चाहिए, इस तरह यह गारंटी है कि राज्य भ्रष्ट नहीं है और आगे बढ़ना सुरक्षित है
• अनियंत्रित अपवाद: तत्काल पहुंच में हुआ या बहुत नीचे, इसे संभाला नहीं जा सकता क्योंकि राज्य भ्रष्ट था, आप इसे लॉग कर सकते हैं या अपने जोखिम पर आगे बढ़ सकते हैं

SyntaxError में JSON.parse को चेक किए गए अपवाद के रूप में घोषित किया जाना चाहिए

@ अलेक्सी-बायकोव

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

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

यह जानकर कि किसी फ़ंक्शन को लागू करते समय कौन सी त्रुटियां फेंकी जा सकती हैं, डेवलपर यह तय कर सकता है कि वह क्या संभालना चाहता है और क्या नहीं।
इससे कोई फर्क नहीं पड़ता कि त्रुटि कितनी गहरी श्रृंखला में डाली गई थी।

देखिए, मैं जो कह रहा हूं वह आपको समझ में नहीं आ रहा है, हम मंडलियों में जा रहे हैं

SyntaxError को तृतीय पक्ष लाइब्रेरी से फेंक कर आप अपने उपयोगकर्ता को अपने कोड के कार्यान्वयन विवरण के बारे में बता रहे हैं, जिसे इनकैप्सुलेट किया जाना है

मूल रूप से आप कह रहे हैं, हे, यह मेरा कोड नहीं है जो काम नहीं करता है, यह वह बेवकूफ पुस्तकालय है जिसे मैंने इंटरनेट पर पाया और इस्तेमाल किया, इसलिए यदि आपको इससे कोई समस्या है, तो उस तीसरे पक्ष के काम से निपटें, मुझे नहीं, मैं बस वही कहा जो मुझसे पूछा गया था

और इस बात की कोई गारंटी नहीं है कि आप उस सिंटेक्स त्रुटि के बाद भी उस तीसरे lib के उदाहरण का उपयोग कर सकते हैं, उपयोगकर्ता को गारंटी प्रदान करने की आपकी ज़िम्मेदारी है, जैसे कि तीसरे पक्ष के नियंत्रण को फेंकने के बाद उसे बहाल करना

नीचे की रेखा, आपको आंतरिक अपवादों को संभालने के लिए प्रभारी होने की आवश्यकता है ( उनमें से सभी नहीं, केवल चेक किए गए हैं, मैं आपसे विनती करता हूं )

आप जो कह रहे हैं वह मुझे मिल रहा है, लेकिन मैं इससे सहमत नहीं हूं।
आप सही कह रहे हैं, मैं मूल रूप से यही कह रहा हूं।
अगर मैंने किसी तृतीय पक्ष लाइब्रेरी का उपयोग किया है जो एक त्रुटि फेंकता है तो मैं इससे निपटना चुन सकता हूं या इसे अनदेखा कर सकता हूं और मेरे कोड के उपयोगकर्ता को इसे संभालने देता हूं।
ऐसा करने के कई कारण हैं, उदाहरण के लिए मैं जो लिब लिख रहा हूं वह यूआई-अज्ञेयवादी है, इसलिए मैं उपयोगकर्ता को सूचित नहीं कर सकता कि कुछ गलत है, लेकिन जो कभी भी मेरे लिब का उपयोग करता है वह उन त्रुटियों को संभाल सकता है जो उपयोग करते समय फेंकी जाती हैं मेरे lib और उपयोगकर्ता के साथ बातचीत करके उन्हें संभाल लें।

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

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

आप असहमत हो सकते हैं, यह ठीक है, चलो बस उन्हें चेक किए गए अपवाद नहीं कहते हैं, क्योंकि जिस तरह से आप इसे डालते हैं वह चेक किए गए अपवाद नहीं हैं

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

@ अलेक्सी-बायकोव
काफी सही, नाम बदल गया।

@ अलेक्सी-बायकोव

आप 20 परतों के नीचे हुई समस्या को इनायत से संभाल नहीं सकते, क्योंकि आंतरिक स्थिति 19 परतों में भ्रष्ट है और आप वहां नहीं जा सकते क्योंकि राज्य निजी है

नहीं, आप आंतरिक स्थिति को ठीक नहीं कर सकते हैं, लेकिन निश्चित रूप से स्थानीय स्थिति को ठीक कर सकते हैं, और यह वास्तव में इसे यहां संभालने का बिंदु है और ढेर में गहरा नहीं है।

यदि आपका तर्क यह है कि यह सुनिश्चित करने का कोई तरीका नहीं है कि अपवाद को संभालने के दौरान कुछ साझा परिवर्तनीय मान किस स्थिति में हैं, तो यह अनिवार्य प्रोग्रामिंग के खिलाफ एक तर्क है, और इस प्रस्ताव तक ही सीमित नहीं है।

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

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

जैसा कहा गया है, प्रस्ताव ज्यादातर बेकार है, क्योंकि आपकी पहुंच से बाहर कुछ बुरा हुआ है, इसके ज्ञान पर प्रतिक्रिया करने का कोई विश्वसनीय तरीका नहीं है

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

@agonzalezjr
मुझे लगता है कि टाइपस्क्रिप्ट में अधिकांश सुविधाओं की तरह आपको भी इस सुविधा के साथ ऑप्ट-इन करने में सक्षम होना चाहिए।
जैसे प्रकार जोड़ना अनिवार्य नहीं है, वैसे ही इसे फेंकना/पकड़ना जरूरी नहीं होना चाहिए।

संभवतः इसे अनिवार्य बनाने के लिए एक झंडा होना चाहिए, जैसे --onlyCheckedExceptions ।

किसी भी मामले में, इस सुविधा का उपयोग फेंके गए अपवादों के प्रकारों का अनुमान लगाने/सत्यापन करने के लिए भी किया जाएगा, न कि केवल दस्तावेज़ीकरण के लिए।

@nitzantomer

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

यह निश्चित रूप से एक ऐसा क्षेत्र है जहां चेक किए गए अपवादों का पूरा विचार अस्पष्ट हो जाता है। यह वह जगह भी है जहां _असाधारण स्थिति_ की परिभाषा अस्पष्ट हो जाती है।
आपके उदाहरण में प्रोग्राम JSON.parse के लिए एक तर्क होगा जिसे चेक किए गए अपवाद को फेंकने के रूप में घोषित किया जा रहा है।
लेकिन क्या होगा यदि प्रोग्राम एक HTTP क्लाइंट है और एक HTTP प्रतिक्रिया से जुड़े शीर्षलेख के मूल्य के आधार पर JSON.parse को कॉल कर रहा है जिसमें एक खराब गठित निकाय होता है? ऐसा कुछ भी अर्थपूर्ण नहीं है जो कार्यक्रम पुनर्प्राप्त करने के लिए कर सकता है, यह केवल इतना कर सकता है कि इसे फिर से फेंक दिया जाए।
मैं कहूंगा कि यह JSON.parse को चेक के रूप में घोषित किए जाने के खिलाफ एक तर्क है।

यह सब उपयोग के मामले पर निर्भर करता है।

मैं समझता हूं कि आप यह प्रस्तावित कर रहे हैं कि यह एक झंडे के नीचे हो, लेकिन आइए कल्पना करें कि मैं इस सुविधा का उपयोग करना चाहता हूं इसलिए मैंने ध्वज को सक्षम किया है। मैं किस तरह का कार्यक्रम लिख रहा हूं, इस पर निर्भर करते हुए, यह मेरी मदद या बाधा उत्पन्न कर सकता है।

यहां तक ​​कि क्लासिक java.io.FileNotFoundException भी इसका एक उदाहरण है। इसकी जाँच की जाती है लेकिन क्या प्रोग्राम ठीक हो सकता है? यह वास्तव में इस बात पर निर्भर करता है कि लापता फ़ाइल का कॉलर के लिए क्या अर्थ है, कैली नहीं।

@aluanhaddad

यह सुझाव किसी भी नई कार्यक्षमता को जोड़ने का प्रस्ताव नहीं करता है, केवल टाइपस्क्रिप्ट में व्यक्त करने का एक तरीका जोड़ने के लिए जो पहले से ही जावास्क्रिप्ट में मौजूद है।
त्रुटियां फेंक दी जाती हैं, लेकिन वर्तमान में टाइपस्क्रिप्ट में उन्हें घोषित करने का कोई तरीका नहीं है (फेंकते या पकड़ते समय)।

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

किसी भी मामले में, डेवलपर को कॉल करना चाहिए कि वह फेंकी गई त्रुटि से उबर सकता है या नहीं।
यह तय करना भी उसके ऊपर है कि पुनर्प्राप्त करने का क्या अर्थ है, उदाहरण के लिए यदि मैं इस http क्लाइंट को तृतीय पक्ष लाइब्रेरी के रूप में उपयोग करने के लिए लिख रहा हूं, तो मैं चाहता हूं कि मेरी लाइब्रेरी से सभी त्रुटियां एक ही प्रकार की हों:

enum ErrorCode {
    IllFormedJsonResponse,
    ...
}
...
{
    code: ErrorCode;
    message: string;
}

अब, मेरी लाइब्रेरी में जब मैं JSON.parse का उपयोग करके प्रतिक्रिया को पार्स करता हूं तो मैं एक फेंकी गई त्रुटि को पकड़ना चाहता हूं और फिर अपनी त्रुटि फेंकना चाहता हूं:

{
    code: ErrorCode.IllFormedJsonResponse,
    message: "Failed parsing response"
} 

यदि यह सुविधा लागू की जाती है तो मेरे लिए इस व्यवहार की घोषणा करना आसान होगा और यह मेरी लाइब्रेरी के उपयोगकर्ताओं के लिए स्पष्ट होगा कि यह कैसे काम करता है और विफल रहता है।

यह सुझाव किसी भी नई कार्यक्षमता को जोड़ने का प्रस्ताव नहीं करता है, केवल टाइपस्क्रिप्ट में व्यक्त करने का एक तरीका जोड़ने के लिए जो पहले से ही जावास्क्रिप्ट में मौजूद है।

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

@aluanhaddad

आपने पिछली टिप्पणी में क्या कहा था:

लेकिन क्या होगा यदि प्रोग्राम एक HTTP क्लाइंट है और एक HTTP प्रतिक्रिया से जुड़े हेडर के मूल्य के आधार पर JSON.parse को कॉल कर रहा है जिसमें एक खराब गठित निकाय होता है? ऐसा कुछ भी अर्थपूर्ण नहीं है जो कार्यक्रम पुनर्प्राप्त करने के लिए कर सकता है, यह केवल इतना कर सकता है कि इसे फिर से फेंक दिया जाए।

जब मेरे फ़ंक्शन को परिणाम वापस करने के लिए घोषित किया जाता है तो null वापस करने के लिए इसे लागू करता है।
यदि डेवलपर strictNullChecks का उपयोग करना चुनता है तो आप वही बात कह सकते हैं यदि फ़ंक्शन null (फेंकने के बजाए) लौटाता है तो उसी परिदृश्य में "कार्यक्रम कुछ भी सार्थक नहीं कर सकता है ठीक करने के लिए"।

लेकिन onlyCheckedExceptions ध्वज का उपयोग किए बिना भी यह सुविधा अभी भी उपयोगी है क्योंकि संकलक शिकायत करेगा उदाहरण के लिए यदि मैं त्रुटि को string के रूप में पकड़ने की कोशिश करता हूं जब फ़ंक्शन केवल Error फेंकने के लिए घोषित किया जाता है

अच्छा विचार, यह मददगार होगा लेकिन सख्त/सुरक्षित नहीं होगा क्योंकि यह जानने का कोई तरीका नहीं है कि कौन सी नेस्टेड कॉल आपको फेंक सकती हैं।

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

(सूत्र बहुत लंबा है - क्षमा करें अगर मैं इस टिप्पणी से चूक गया)

@shaipetel
प्रस्ताव में कहा गया है कि कंपाइलर अनहेल्ड एरर के प्रकारों का अनुमान लगाएगा और उन्हें फंक्शन/मेथड सिग्नेचर में जोड़ देगा।
इसलिए यदि आपने वर्णन किया है कि आपका फ़ंक्शन A | B फेंक देगा यदि B को संभाला नहीं गया था।

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

@shaipetel
जावास्क्रिप्ट में सभी त्रुटियां Error वर्ग पर आधारित हैं, लेकिन आप त्रुटियों को फेंकने तक ही सीमित नहीं हैं, आप कुछ भी फेंक सकते हैं:

• throw "something went wrong"
• throw 0
• throw { message: "something went wrong", code: 4 }

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

तो, यह "फेंक 0" या "फेंक 'कुछ त्रुटि' की अनुमति नहीं देगा"।
जैसे जावास्क्रिप्ट कई चीजों की अनुमति देता है टाइपस्क्रिप्ट नहीं करता है।

धन्यवाद,

@nitzantomer

जब मेरे फ़ंक्शन को परिणाम वापस करने के लिए घोषित किया जाता है तो यह शून्य वापस करने के लिए लागू होता है।
यदि डेवलपर सख्त नलचेक का उपयोग करना चुनता है तो आप वही बात कह सकते हैं यदि फ़ंक्शन एक शून्य (फेंकने के बजाए) देता है तो उसी परिदृश्य में "कुछ भी सार्थक नहीं है जो प्रोग्राम पुनर्प्राप्त करने के लिए कर सकता है"।

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

मैं देख रहा हूँ कि आप क्या कह रहे हैं, यह समझ में आता है।

@shaipetel जैसा कि पहले इस प्रस्ताव और अन्य जगहों पर चर्चा की गई थी, Error और Array जैसे कार्यों में निर्मित उपवर्ग काम नहीं करता है। यह व्यवहार की ओर जाता है जो व्यापक रूप से उपयोग किए जाने वाले रन टाइम और संकलन लक्ष्यों में भिन्न होता है।

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

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

मैं टाइप किए गए अपवादों को संभालने के लिए किसी प्रकार का सहायक तर्क होना पसंद करूंगा, मैं async/प्रतीक्षा का उपयोग करने के लिए बहुत सारे वादे कोड को दोबारा कर रहा हूं, जो वर्तमान में दिखता है:

doSomethingWhichReturnsPromise()
    .then(send(200))
    .catch(NotFoundError, (error) => { send(404); })
    .catch(SomeBadDataError, (error) => { send(400); })
    .catch(CantSeeThisError, (error) => { send(403); })
    .catch((error) => { send(500); })

फिर नई दुनिया में ऐसा दिखता है:

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch(error)
{
    if(error instanceof NotFoundError) { send(404); } 
    else if(error instanceof SomeBadDataError) { send(400); } 
    else if(error instanceof CantSeeThisError) { send(403); } 
    else { send(500); } 
}

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

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch(NotFoundError, error) { send(404); }
catch(SomeBadDataError, error) { send(404); }
catch(CantSeeThisError, error) { send(404); }
catch(error) { send(404); }

जो पिछले बिट को आउटपुट करेगा, लेकिन सिंटैक्टिक शुगर के रूप में, आप इसे जेनेरिक के रूप में भी कर सकते हैं, लेकिन यह थोड़ा नास्टियर है:

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch<NotFoundError>(error) { send(404); }
catch<SomeBadDataError>(error) { send(404); }
catch<CantSeeThisError>(error) { send(404); }
catch(error) { send(404); }

@grofit
जबकि मुझे यह पसंद है यदि टाइपस्क्रिप्ट आपके सुझाव का समर्थन करेगा, तो यह मेरी राय में इस मुद्दे से संबंधित नहीं है।
आप जो सुझाव दे रहे हैं उसे लागू किए बिना भी लागू किया जा सकता है कि यह समस्या किस बारे में है, बस संकलक शिकायत करने में सक्षम नहीं होगा (उदाहरण के लिए) कि NotFoundError फेंका नहीं गया है।

मैंने सोचा कि यह टाइप किए गए कैच के लिए एक सुझाव था, किसी भी तरह का मुद्दा नहीं, मैं सिर्फ धागे को डुप्लिकेट नहीं करना चाहता था, फिर इसे अपने मुद्दे पर पोस्ट कर दूंगा।

@grofit
टाइप किए गए कैच भी फीचर अनुरोध का हिस्सा हैं, लेकिन संकलक को यह सूचित करने की क्षमता भी है कि कार्यों से किस प्रकार की त्रुटियां फेंकी जा सकती हैं (और फिर संकलक यह भी अनुमान लगाने में सक्षम होगा कि किस प्रकार की त्रुटियां फेंकी जा सकती हैं)।

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

@grofit

जो पिछले बिट को आउटपुट करेगा, लेकिन सिंटैक्टिक शुगर के रूप में, आप इसे जेनेरिक के रूप में भी कर सकते हैं, लेकिन यह थोड़ा नास्टियर है:

try
{
  await doSomethingWhichReturnsPromise();
  send(200);
}
catch<NotFoundError>(error) { send(404); }
catch<SomeBadDataError>(error) { send(404); }
catch<CantSeeThisError>(error) { send(404); }
catch(error) { send(404); }

काम नहीं करने वाला है क्योंकि इसका तात्पर्य केवल प्रकारों के आधार पर कोड बनाना है जबकि

 doSomethingWhichReturnsPromise()
    .then(send(200))
    .catch(NotFoundError, (error) => { send(404); })
    .catch(SomeBadDataError, (error) => { send(400); })
    .catch(CantSeeThisError, (error) => { send(403); })
    .catch((error) => { send(500); })

प्रत्येक मामले में त्रुटि फ़ंक्शन पास करता है और संभवतः instanceof के साथ कार्यान्वित किया जाता है। इस तरह का कोड विषाक्त है क्योंकि यह Error को बढ़ाने के लिए प्रोत्साहित करता है जो कि बहुत बुरी बात है।

@nitzantomer मैं मानता हूं कि यह एक अलग मुद्दा है। ओपी के पास पकड़ने वाले प्रकारों के उदाहरण हैं जो Error का विस्तार नहीं करते हैं।

@aluanhaddad
@grofit आपसे जो मांगता है उसके लिए आप कुछ ऐसा कर सकते हैं:

try {
    // do something
} catch (isNotFoundError(error)) {
    ...
}  catch (isSomeBadDataError(error)) {
    ...
} catch (error) {
    ...
}

जहां isXXX(error) इस प्रकार के गार्ड हैं:
function isXXX(error): error is XXX { ... }

@nitzantomer यकीन है, लेकिन टाइप गार्ड मुद्दा नहीं हैं। मुद्दा है

class MyError extends Error {
  myErrorInfo: string;
}

जो समस्याग्रस्त है, लेकिन यहां पहले ही चर्चा की जा चुकी है। मैं इस मुद्दे पर विस्तार से विचार नहीं करना चाहता, लेकिन इस घटिया प्रथा को अपनाने से कई बड़े और प्रसिद्ध कोड बेस नकारात्मक रूप से प्रभावित हुए हैं। Error का विस्तार करना एक बुरा विचार है।

@aluanhaddad
मुझे इसके बारे में पता है, यही वजह है कि मैंने @grofit के अनुरोध को पूरा करने का एक तरीका पेश किया लेकिन Error को बढ़ाने की आवश्यकता के बिना। एक डेवलपर अभी भी Error का विस्तार करने में सक्षम होगा यदि वह चाहता है, लेकिन संकलक जेएस कोड उत्पन्न करने में सक्षम होगा जिसे instanceof का उपयोग करने की आवश्यकता नहीं है

@nitzantomer मुझे एहसास है कि आप जागरूक हैं, लेकिन मुझे नहीं पता था कि आप @grofit को क्या सुझाव दे रहे थे जो एक अच्छा विचार की तरह लगता है।

मैं सिर्फ एक मरे हुए घोड़े को मार रहा हूं क्योंकि मुझे एपीआई से निपटना पसंद नहीं है जो मुझे ऐसे पैटर्न का उपयोग करना चाहते हैं। भले ही, अगर मैंने इस चर्चा को विषय से हटा दिया तो मुझे खेद है।

क्या इस चर्चा में कोई और विचार आया है? मुझे टाइपप्रति में throws क्लॉज देखना अच्छा लगेगा।

@aluanhaddad आप कहते रहते हैं कि Error का विस्तार करना बुरा व्यवहार है। क्या आप इस पर थोड़ा विस्तार कर सकते हैं?

इस पर लंबी चर्चा हुई है। मूल रूप से आप बिल्ट-इन प्रकारों का मज़बूती से विस्तार नहीं कर सकते। वातावरण और --target सेटिंग्स के संयोजन में व्यवहार नाटकीय रूप से भिन्न होता है।

मैंने केवल यही कारण पूछा कि आपकी टिप्पणियाँ सबसे पहले मैंने इसके बारे में सुना था। थोड़ा गुगली करने के बाद, मुझे केवल यह बताने वाले लेख मिले कि कैसे और क्यों _ should_ का विस्तार Error होना चाहिए।

नहीं यह काम नहीं करेगा। आप इसके बारे में विस्तार से https://github.com/Microsoft/TypeScript/issues/12123 और कई जुड़े मुद्दों में पढ़ सकते हैं।

यह काम करेगा, लेकिन केवल "विशिष्ट वातावरण" में, जो बहुमत बन रहे हैं क्योंकि ES6 को अनुकूलित किया जा रहा है।

@nitzantomer : क्या आपको लगता है कि एक TSLint चेक लागू करना संभव है जो डेवलपर को सूचित करता है जब @throws वाले फ़ंक्शन को आसपास के try/catch के बिना कॉल किया जाता है?

@bennyn मैं एक TSLint उपयोगकर्ता हूं, लेकिन मैंने कभी भी नए नियम बनाने पर ध्यान नहीं दिया।
मैं वास्तव में नहीं जानता कि क्या यह संभव है (हालांकि मुझे लगता है कि यह है), और यदि ऐसा है तो कितना आसान है।

यदि आप इसे आज़माते हैं, तो कृपया यहां अपडेट करें, धन्यवाद।

@shaipetel (और @nitzantomer भी)

पुनः:

हाँ, मुझे पता है कि जावास्क्रिप्ट कैसे काम करता है, हम टाइपस्क्रिप्ट पर चर्चा कर रहे हैं जो आगे की सीमाएँ निर्धारित करता है।
मैंने सुझाव दिया, एक अच्छा समाधान आईएमएचओ मेक टाइपस्क्रिप्ट अपवाद हैंडलिंग का पालन करेगा जिसके लिए सभी फेंके गए अपवादों को एक विशिष्ट बेस क्लास की आवश्यकता होती है और सीधे अनचाहे मूल्यों को फेंकने की अनुमति नहीं दी जाती है।
तो, यह "फेंक 0" या "फेंक 'कुछ त्रुटि' की अनुमति नहीं देगा"।
जैसे जावास्क्रिप्ट कई चीजों की अनुमति देता है टाइपस्क्रिप्ट नहीं करता है।

सुनिश्चित नहीं है कि यह वही है जो आप @shaipetel का सुझाव दे रहे थे, लेकिन सिर्फ मामले में ... मैं टाइपस्क्रिप्ट को throw को केवल Error s वापस करने के लिए प्रतिबंधित करने के खिलाफ सावधानी बरतता हूं। रिएक्ट की आगामी Async रेंडरिंग सुविधाएँ throw ing Promise s द्वारा हुड के तहत काम करती हैं! (मुझे पता है कि अजीब लगता है ... लेकिन मैंने पढ़ा है कि उन्होंने इसका मूल्यांकन किया है बनाम async / await और yield / yield* जनरेटर उनके उपयोग के मामले के लिए और मुझे यकीन है कि वे जानते हैं कि वे क्या कर रहे हैं!)

throw आईएनजी Error s क्या मुझे यकीन है कि 99% उपयोग के मामले हैं, लेकिन 100% नहीं। मुझे नहीं लगता कि टाइपस्क्रिप्ट को उपयोगकर्ताओं को केवल throw उन चीजों तक सीमित रखना चाहिए जो Error बेस क्लास का विस्तार करती हैं। यह निश्चित रूप से बहुत अधिक उन्नत है, लेकिन throw में त्रुटियों/अपवादों के अलावा अन्य उपयोग के मामले हैं।

@ मिकेलियोनार्ड
मैं सहमत हूं, मौजूदा जेएस कोड के कई उदाहरण हैं जो विभिन्न प्रकार के फेंकते हैं (मैंने बहुत सारे throw "error message string" देखे हैं)।
नया रिएक्ट फीचर एक और अच्छा उदाहरण है।

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

यह टाइप करने की अनुमति देने के लिए एक प्राकृतिक विस्तार की तरह लगता है कि कोई फ़ंक्शन क्या फेंकता है। रिटर्न वैल्यू को वैकल्पिक रूप से टीएस में टाइप किया जा सकता है, और मेरे लिए ऐसा लगता है कि थ्रो सिर्फ एक अन्य प्रकार का रिटर्न है (जैसा कि थ्रो से बचने के लिए सुझाए गए सभी विकल्पों से प्रमाणित है, जैसे https://stackoverflow.com/a/39209039/162530)।

(व्यक्तिगत रूप से, मुझे यह लागू करने के लिए (वैकल्पिक) कंपाइलर विकल्प भी पसंद आएगा कि किसी भी कॉलर को थ्रो के रूप में घोषित किए गए फ़ंक्शन को या तो थ्रो के रूप में घोषित करना चाहिए या उन्हें पकड़ना चाहिए।)

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

@aleksey-bykov आइए जावास्क्रिप्ट की प्रकृति को न बदलें, आइए बस इसमें टाइपिंग जोड़ दें। :)

टाइपिंग जोड़ने से यह पहले से ही बदल जाता है (कोड को काट देता है जिसका कोई मतलब नहीं है),
उसी तरह हम अपवाद हैंडलिंग को कड़ा कर सकते हैं

गुरु, 26 जुलाई, 2018 को, 8:22 अपराह्न जो मटर अधिसूचनाएं @github.com ने लिखा:

@aleksey-bykov https://github.com/aleksey-bykov आइए इसे न बदलें
जावास्क्रिप्ट की प्रकृति, आइए बस इसमें टाइपिंग जोड़ दें। :)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/13219#issuecomment-408274156 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA5PzfUNS5E093Z74WA4WCUaTyWRRZC3ks5uKl1FgaJpZM4LXwLC
.

वादों के लिए, यदि आप async/wait के बजाय then श्रृखंला का उपयोग करते हैं और throw का उपयोग करने से बचते हैं, तो यह सब वास्तव में काफी खूबसूरती से काम करता है। यहाँ अवधारणा स्केच का प्रमाण दिया गया है:

https://bit.ly/2NQZD8i - खेल का मैदान लिंक

interface SafePromise<T, E> {
    then<U, E2>(
        f: (t: T) => SafePromise<U, E2>):
        SafePromise<U, E | E2>;

    catch<U, E2>(
        f: (e: E) => SafePromise<U, E2>):
        SafePromise<U, E2>

    catch<U, E1, E2>(
        guard: (e: any) => e is E1,
        f: (e: E) => SafePromise<U, E2>):
        SafePromise<U, Exclude<E, E1> | E2>
}

declare function resolve<T>(t:T): SafePromise<T, never>
declare function reject<E extends Error>(e:E): SafePromise<never, E>


class E404 extends Error {
    code:404 = 404;
}

class E403 extends Error {
    code:403 = 403;
    static check(e: any): e is E403 { return e && e.code === 403 }
}

let p = resolve(20)


let oneError = p.then(function f(x) {
    if (x > 5) return reject(new E403())
    return resolve(x)
})


let secondError = oneError.then(x => {
    if (x > 10) return reject(new E404())
    return resolve(x)
})

let remove403 = secondError.catch(E403.check, e => {
    return resolve(25)
})

let moreErrorsInfer = p.then(x => {
    if (x > 5) return reject(new E403())
    if (x > 10) return reject(new E404())
    return resolve(x)
})

let moreErrorsNoInfer = p.then((x):SafePromise<number, E403|E404> => {
    if (x > 5) return reject(new E403())
    if (x > 10) return reject(new E404())
    return resolve(x)
})

विधेय पकड़ संघ से प्रकारों को हटाता है, जबकि एक reject() लौटाता है जो उन्हें जोड़ता है। केवल एक चीज जो काफी काम नहीं करती है वह है संघ-पैरामीटर प्रकारों का अनुमान (शायद एक बग)

ऊपर के उदाहरण में संबोधित समस्याएं:

• यह त्रुटियों तक ही सीमित नहीं है, आप किसी भी चीज़ को अस्वीकार कर सकते हैं (हालाँकि शायद एक बुरा विचार है)
• यह उदाहरण का उपयोग करने तक ही सीमित नहीं है, आप संघ से त्रुटियों को दूर करने के लिए किसी भी विधेय प्रकार के गार्ड का उपयोग कर सकते हैं

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

declare function pureMap<T>(t:T[], f: (x:T) => U throws never):U[] throws never

हस्ताक्षर के बिना संस्करण:

declare function dirtyMap<T>(t:T[], f: (x:T) => U):U[]

वास्तव में डिफ़ॉल्ट होगा

declare function dirtyMap<T>(t:T[], f: (x:T) => U throws any):U[] throws any

यह गारंटी देने के लिए कि सभी मौजूदा कोड संकलित हैं।

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

मुझे लगता है कि वादा और async/await पर ध्यान केंद्रित करने के लिए एक अच्छा मध्य मैदान होगा, क्योंकि वादा पहले से ही एक रैपर है, और एसिंक कोड वह जगह है जहां विशिष्ट परिदृश्यों में त्रुटि प्रबंधन शाखाएं सबसे अधिक होती हैं। अन्य त्रुटियां "अनचेक" होंगी

@ spion-h4 क्या यह (पहले से ही/इच्छा) टाइपप्रति पर उपयोग कर सकता है?

declare function dirtyMap<T>(t:T[], f: (x:T) => U throws any):U[] throws any

@ब्लूलोवर्स
नहीं, टाइपस्क्रिप्ट वर्तमान में throws कीवर्ड का समर्थन नहीं करता है, यही समस्या है।

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

उदाहरण:

class AnotherError extends Error {}

function* range(min: number, max: number): Iterable<number> throws TypeError, RangeError {
  if (typeof min !== 'number') {
    throw new TypeError('min must be a number')
  }
  if (typeof min !== 'number') {
    throw new TypeError('max must be a number')
  }
  if (!Number.isSafeInteger(min)) {
    // Allowed because without nominal types we can't distinguish
    // Error/RangeError/TypeError/etc
    throw new Error('min must be a safe integer')
  }
  if (!Number.isSafeInteger(max)) {
    // Also allowed because AnotherError is also structurally
    // compatible with TypeError/RangeError
    throw new AnotherError('max must be a safe integer')
  }
  for (let i = min; i < max; i++) {
    yield i
  }
}

@Jamesernator
इस मुद्दे का प्रस्ताव से कोई लेना-देना नहीं है।
आप ऐसा करने में एक ही सटीक समस्या में पड़ सकते हैं:

class BaseClass {
    propA!: string;
}

class MyClass1 extends BaseClass { }

class MyClass2 extends BaseClass { }

function fn(): MyClass1 {
    return new MyClass2();
}

यह एक भाषा सीमा है जो बहुत सारे उपयोग के मामलों को प्रभावित करती है।

टाइप किए गए अपवादों पर @ahejlsberg द्वारा एक महान पढ़ा गया है: https://www.artima.com/intv/handcuffs.html

मेरा मानना ​​है कि इन मुद्दों से बचने के लिए टाइपस्क्रिप्ट एक अच्छी स्थिति में है। टाइपस्क्रिप्ट _वास्तविक-विश्व_समस्याओं के _व्यावहारिक_ समाधान के बारे में है। मेरे अनुभव में, बड़े जावास्क्रिप्ट और टाइपस्क्रिप्ट कोडबेस में, त्रुटि प्रबंधन सबसे बड़ी समस्याओं में से एक है - यह देखना कि कौन सी त्रुटियां काम करती हैं _might_ थ्रो और मैं _might_ को संभालना चाहता हूं, अविश्वसनीय रूप से कठिन है। यह केवल अच्छे प्रलेखन को पढ़ने और लिखने के माध्यम से संभव है (हम सभी जानते हैं कि हम इस पर कितने अच्छे हैं) या कार्यान्वयन को देखते हुए, और चूंकि वापसी मूल्यों के विपरीत, अपवाद केवल फ़ंक्शन कॉल के माध्यम से स्वचालित रूप से फैलते हैं, यह केवल के लिए पर्याप्त नहीं है सीधे बुलाए गए फ़ंक्शन की जांच करें, लेकिन सभी को पकड़ने के लिए, आपको नेस्टेड फ़ंक्शन कॉल भी जांचना होगा। _यह एक वास्तविक दुनिया की समस्या है_।

जावास्क्रिप्ट में त्रुटियां वास्तव में बहुत उपयोगी मूल्य हैं। NodeJS में कई एपीआई विस्तृत त्रुटि ऑब्जेक्ट फेंकते हैं, जिनमें अच्छी तरह से परिभाषित त्रुटि कोड होते हैं और उपयोगी मेटाडेटा को उजागर करते हैं। उदाहरण के लिए, child_process.execFile() की त्रुटियों में exitCode और stderr जैसे गुण हैं, $# fs.readFile() की त्रुटियों में त्रुटि कोड हैं जैसे ENOENT (फ़ाइल नहीं मिली ) या EPERM (अपर्याप्त अनुमतियां)। मैं कई पुस्तकालयों को जानता हूं जो ऐसा भी करते हैं, उदाहरण के लिए pg डेटाबेस ड्राइवर आपको एक त्रुटि पर पर्याप्त मेटाडेटा देता है यह जानने के लिए कि किस सटीक कॉलम बाधा के कारण INSERT विफल हो गया।

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

यदि हम @types घोषणाओं और lib.d.ts में परिभाषित कर सकते हैं कि ये फ़ंक्शन कौन सी त्रुटियां फेंक सकते हैं, तो टाइपस्क्रिप्ट में त्रुटि की संरचना के साथ हमारी सहायता करने की शक्ति होगी - इसमें कौन सी संभावित त्रुटियां हो सकती हैं, कौन सी त्रुटियां हो सकती हैं त्रुटि कोड मान हैं, उनके पास कौन से गुण हैं। यह टाइप किए गए अपवादों के बारे में _not_ है और इसलिए टाइप किए गए अपवादों के साथ सभी मुद्दों से पूरी तरह से बचा जाता है। यह एक _वास्तविक दुनिया की समस्या_ के लिए एक व्यावहारिक समाधान है (लोगों को इसके बजाय मोनैडिक त्रुटि वापसी मूल्यों का उपयोग करने के लिए कहने के विपरीत - जावास्क्रिप्ट भूमि की वास्तविकता अलग दिखती है, कार्य त्रुटियां फेंकते हैं)।

एनोटेशन पूरी तरह से वैकल्पिक हो सकता है (या एक कंपाइलर ध्वज के साथ आवश्यक बनाया गया)। यदि घोषणा फ़ाइल में निर्दिष्ट नहीं है, तो फ़ंक्शन केवल any (या unknown ) फेंकता है।
एक फ़ंक्शन मैन्युअल रूप से throws never के साथ कभी नहीं फेंकने की घोषणा कर सकता है।
यदि कार्यान्वयन उपलब्ध है, तो एक फ़ंक्शन उन सभी अपवाद प्रकारों का एक संघ फेंकता है जिन्हें वह कॉल करता है और इसके अपने throw कथन जो catch के साथ try ब्लॉक के अंदर नहीं हैं catch खंड।
यदि उनमें से कोई any फेंकता है, तो फ़ंक्शन any भी फेंकता है - यह ठीक है, प्रत्येक फ़ंक्शन सीमा पर देव के पास स्पष्ट एनोटेशन के माध्यम से इसे ठीक करने का अवसर होता है।
और कई मामलों में, जहां एक प्रसिद्ध फ़ंक्शन को कॉल किया जाता है और एक कोशिश/पकड़ में लपेटा जाता है (उदाहरण के लिए एक फ़ाइल पढ़ना और इसे संभालना नहीं मिल रहा है), टाइपस्क्रिप्ट तब कैच क्लॉज में प्रकार का अनुमान लगा सकता है।

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

त्रुटि प्रकारों को परिभाषित करना

interface ExecError extends Error {
  status: number
  stderr: Buffer
}
function execFileSync(cmd: string): Buffer throws ExecError;

interface NoEntityError extends Error { code: 'ENOENT' }
interface PermissionError extends Error { code: 'EPERM' }
function readFileSync(file: string): Buffer throws NoEntityError | PermissionError;



md5-818797fe8809b5d8696f479ce1db4511



Preventing a runtime error due to type mismatch



md5-c2d214f4f8ecd267a9c9252f452d6588



Catching errors with type switch



md5-75d750bbe0c3494376581eaa3fa62ce5



```ts
try {
  const resp = await fetch(url, { signal })
  if (!resp.ok) {
    // inferred error type
    // look ma, no Error subclassing!
    throw Object.assign(new Error(resp.statusText), { name: 'ResponseError', response })
  }
  const data = await resp.json()
} catch (err) { // AbortError | Error & { name: 'ResponseError', response: Response } | SyntaxError
  switch (err.name)
    case 'AbortError': return; // Don't show AbortErrors
    default: displayError(err); return;
  }
}



md5-a859955ab2c42d8ce6aeedfbb6443e93



```ts
interface HttpError extends Error { status: number }
// Type-safe alternative to express-style middleware request patching - just call it (TM)
// The default express error handler recognises the status property
function checkAuth(req: Request): User throws HttpError {
    const header = req.headers.get('Authorization')
    if (!header) {
        throw Object.assign(new Error('No Authorization header'), { status: 401 })
    }
    try {
        return parseHeader(header)
    } catch (err) {
        throw Object.assign(new Error('Invalid Authorization header'), { status: 401 })
    }
}

त्रुटियों के अलावा, क्या अन्य प्रकार के दुष्प्रभावों को भी चिन्हित करना संभव है जैसे

• विचलन (अनंत लूप/वापसी नहीं)
• आईओ
• गैर-निर्धारणवाद ( Math.random )

यह मुझे एमएसआर से कोका की याद दिलाता है जो रिटर्निंग प्रकारों पर प्रभाव डाल सकता है।

प्रस्ताव:

function square(x: number): number &! never { // This function is pure
  return x * x
}

function square2(x : number) : number &! IO {
  console.log("a not so secret side-effect")
  return x * x
}

function square3( x : number ) : number &! Divergence {
  square3(x)
  return x * x
}

function square4( x : number ) : number &! Throws<string> { // Or maybe a simple `number &! Throws`?
  throw "oops"
  return x * x
}

function map<T, R, E>(a: T[], f :(item: T) => R &! E): R[] &! E { ... }
function map<T, R>(a: T[], f :(item: T) => R): R[] { ... } // will also work; TS would collect side effects

function str<T>(x: T): string &! (T.toString.!) // care about the side effect of a type

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

पुनश्च. https://github.com/Microsoft/TypeScript/issues/13219#issuecomment -428696412 में सिंटैक्स बहुत अच्छा दिखता है - &! और <> में त्रुटि प्रकारों को लपेटना बस अद्भुत है।

मैं भी इसके पक्ष में हूं। अब सभी त्रुटियां टाइप नहीं की गई हैं और यह काफी कष्टप्रद है। हालांकि मुझे उम्मीद है कि अधिकांश throws कोड से प्राप्त किया जा सकता है, हमें इसे हर जगह लिखना है।

इस तरह लोग tslint नियम भी लिख सकते हैं जो डेवलपर को बाकी एंडपॉइंट आदि पर उपयोगकर्ता के अनुकूल त्रुटियों को पकड़ने के लिए मजबूर करता है।

मैं वास्तव में हैरान था कि यह कार्यक्षमता टाइपस्क्रिप्ट के अंदर _already_ नहीं थी। पहली चीजों में से एक जिसे मैं घोषित करने गया था। यह ठीक होगा यदि संकलक इसे लागू करता है या नहीं करता है, जब तक आप यह जानकारी प्राप्त कर सकते हैं कि एक फेंकी गई त्रुटि होगी, और किस प्रकार की त्रुटियां फेंकी जाएंगी।

भले ही हमें &! न मिले और केवल Throws<T> प्राप्त करें जो कि :+1 होगा:

यह वही है जो मेरे मन में है, यह और अधिक सुंदर होगा यदि टाइपस्क्रिप्ट इन खंडों का समर्थन करता है।

एक और संभावित विशेषता यह होगी कि किसी तरह (शायद फ़ंक्शन स्तर पर, या मॉड्यूल स्तर पर) सख्त एक्सेप्शनट्रैकिंग - जिसका अर्थ है कि आपको throws X के रूप में घोषित किसी भी चीज़ को $#$ try! invokeSomething() अभिव्यक्ति के साथ लागू करना होगा। जैसे जंग और तेज में।

यह केवल invokeSomething() के लिए संकलित होगा लेकिन अपवादों की संभावना कोड में दिखाई देगी, जिससे यह पता लगाना आसान हो जाता है कि क्या आप खराब क्षणिक स्थिति में कुछ परिवर्तनशील छोड़ रहे हैं (या आवंटित संसाधनों को बिना निपटाए छोड़ रहे हैं)

@be5invis

function square(x: number): number &! never { // This function is pure
  return x * x
}
...

मैं यहाँ सिर्फ अपने दो सेंट दे रहा हूँ लेकिन &! मुझे अविश्वसनीय रूप से बदसूरत लग रहा है।
मुझे लगता है कि जो लोग टाइपस्क्रिप्ट के लिए नए हैं वे इस प्रतीक से दूर हो जाएंगे, यह वास्तव में बिन बुलाए है।
एक साधारण throws मेरी राय में अधिक स्पष्ट, सहज और सरल है।

इसके अलावा, टाइप किए गए अपवादों के लिए +1। मैं

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

उन लोगों के लिए जो टाइपस्क्रिप्ट में संकलन-समय त्रुटि सुरक्षा की तलाश में हैं, आप मेरी ts-results लाइब्रेरी का उपयोग कर सकते हैं।

दुर्भाग्य से मेरे लिए @vultix , इसे टीम सेटिंग में रखने के लिए अलगाव पर्याप्त नहीं है।

@vultix आपके lib के दृष्टिकोण पर ऊपर चर्चा की गई है, और यह हल करने के लिए यह सुविधा यहां क्या है इसके ठीक विपरीत है।
जावास्क्रिप्ट में पहले से ही त्रुटियों से निपटने के लिए तंत्र है, इसे अपवाद कहा जाता है, लेकिन टाइपस्क्रिप्ट में इसका वर्णन करने का एक तरीका नहीं है।

@nitzantomer मैं पूरी तरह से सहमत हूं कि यह सुविधा टाइपस्क्रिप्ट के लिए एक आवश्यकता है। मेरी लाइब्रेरी अस्थायी स्टैंड-इन से ज्यादा कुछ नहीं है जब तक कि यह सुविधा नहीं जोड़ी जाती।

function* range(min: number, max: number): Iterable<number> throws TypeError, RangeError {

मुझे पता है कि मुझे इस खेल में थोड़ी देर हो गई है, लेकिन नीचे अल्पविराम के बजाय थोड़ा अधिक टाइपस्क्रिप्ट सिंटैक्स लगता है।

Iterable<number> throws TypeError | RangeError

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

@WORMSS
मैं पूरी तरह से सहमत हुँ।
मेरे प्रस्ताव में आपके द्वारा अनुशंसित सिंटैक्स शामिल है:

function mightThrow(): void throws string | MyErrorType { ... }

क्या हम जावा जैसी ओओपी भाषा के त्रुटि घोषणा पैटर्न का पालन कर सकते हैं? "थ्रो" कीवर्ड का उपयोग यह घोषित करने के लिए किया जाता है कि संभावित त्रुटि वाले फ़ंक्शन का उपयोग करते समय हमें "try..catch" करने की आवश्यकता है

@allicanseenow
प्रस्ताव थ्रो क्लॉज के वैकल्पिक उपयोग के लिए है।
यही है, यदि आप किसी ऐसे फ़ंक्शन का उपयोग कर रहे हैं जो फेंकता है तो आपको कोशिश/पकड़ का उपयोग नहीं करना पड़ेगा।

@allicanseenow आप संदर्भ के लिए उपरोक्त मेरे राइटअप को पढ़ना चाह सकते हैं, जिसमें लिंक किए गए लेख भी शामिल हैं: https://github.com/microsoft/TypeScript/issues/13219#issuecomment -416001890

मुझे लगता है कि यह टाइपस्क्रिप्ट टाइप सिस्टम में गायब चीजों में से एक है।
यह पूरी तरह से वैकल्पिक है, उत्सर्जित कोड नहीं बदलता है, पुस्तकालयों और मूल कार्यों के साथ काम करने में मदद करता है।

यह भी जानना कि कौन सी त्रुटियां फेंकी जा सकती हैं, संपादकों को सभी त्रुटियों को संभालने के लिए शर्तों के साथ "स्वत: पूर्ण" पकड़ने की अनुमति दे सकती है।

मेरा मतलब है, वास्तव में यहां तक ​​​​कि छोटे आवेदन भी उचित त्रुटि प्रबंधन के योग्य हैं - अब सबसे बुरी बात यह है कि उपयोगकर्ता नहीं जानते कि कुछ गलत हो सकता है।

मेरे लिए, यह अब टॉप मिसिंग फीचर है।

@RyanCavanaugh , "अधिक प्रतिक्रिया की प्रतीक्षा" लेबल जोड़े जाने के बाद से प्रतिक्रिया का एक समूह रहा है। क्या कोई टाइपस्क्रिप्ट टीम के सदस्य वजन कर सकते हैं?

@nitzantomer मैं टाइपस्क्रिप्ट में थ्रो जोड़ने के विचार का समर्थन करता हूं, लेकिन नेस्टेड फ़ंक्शंस में उपयोग किए जाने पर संभावित रूप से गलत थ्रो घोषणाओं के लिए वैकल्पिक प्रयास/पकड़ की अनुमति नहीं देगा?

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

@ConnorSinnott
मुझे आशा है कि मैं आपको सही समझ रहा हूँ:

कंपाइलर फेंके गए प्रकारों का अनुमान लगाएगा, उदाहरण के लिए:

function fn() {
    if (something) {
        throw "something happened";
    }
}

वास्तव में function fn(): throws string { ... } होगा।
घोषित त्रुटियों और वास्तविक त्रुटियों के बीच एक बेमेल होने पर संकलक भी त्रुटि करेगा:

function fn1() throws string | MyError {
    ...
}

function fn2() throws string {
    fn1(); // throws but not catched

    if (something) {
        throws "damn!";
    }
}

संकलक को शिकायत करनी चाहिए कि fn2 फेंकता है string | MyError न कि string ।

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

और इस समस्या के साथ भी, यह काफी हद तक वैसा ही है जैसा अभी है:

// can throw SyntaxError
declare function a_fancy_3rd_party_lib_function(): MyType;

function fn1() {
    if (something) {
        throws "damn!";
    }

    if (something else) {
        throws new Error("oops");
    }

    a_fancy_3rd_party_lib_function();
}

function fn2() {
    try {
        fn1();
    } catch(e) {
        if (typeof e === "string") { ... }
        else if (e instanceof MyError) { ... }
    }
}

हम इससे भी टाइपस्क्रिप्ट की रक्षा कर सकते हैं, लेकिन इसके लिए एक सिंटैक्स की आवश्यकता होगी जो जावास्क्रिप्ट से थोड़ा अलग है:

function fn2() {
    try {
        fn1();
    } catch(typeof e === "string") {
        ...
    } catch(e instanceof MyError) {
        ...
    }
}

इसे संकलित किया जाएगा:

function fn2() {
    try {
        fn1();
    } catch(e) {
        if (typeof e === "string") {}
        else if (e instanceof MyError) {} 
        else {
            throw e;
        }
    }
}

अरे! उत्तर देने के लिये धन्यवाद! वास्तव में, जैसा कि आपने उल्लेख किया है, थ्रो का अनुमान इस मुद्दे को कम करता है जिसके बारे में मैं सोच रहा था। लेकिन आपके द्वारा सूचीबद्ध दूसरा उदाहरण दिलचस्प है।

दिया गया

function first() : string throws MyVeryImportantError { // Compiler complains: missing number and string
    if(something) {
        throw MyVeryImportantError
    } else {
        return second().toString();
    }
}

function second() : number {
    if(something)
        throw 5;
    else   
        return third();
}

function third() : number throws string {
    if(!something)
        throw 'oh no!';
    return 9;
}

मेरे लिए MyVeryImportantError को स्पष्ट रूप से घोषित करने के लिए, मुझे कॉलस्टैक की सभी अतिरिक्त त्रुटियों को भी स्पष्ट रूप से घोषित करना होगा, जो कि आवेदन की गहराई के आधार पर मुट्ठी भर हो सकता है। इसके अलावा, संभावित रूप से थकाऊ। मैं निश्चित रूप से संभावित त्रुटियों की एक सूची उत्पन्न करने के लिए पूरी कॉल श्रृंखला को नीचे नहीं डालना चाहता जो रास्ते में उत्पन्न हो सकती हैं, लेकिन शायद आईडीई मदद कर सकता है।

मैं डेवलपर को स्पष्ट रूप से अपनी त्रुटि घोषित करने और शेष को फेंकने की अनुमति देने के लिए किसी प्रकार के स्प्रेड ऑपरेटर का प्रस्ताव देने के बारे में सोच रहा था।

function first() : string throws MyVeryImportantError | ... { // Spread the rest of the errors

लेकिन एक ही परिणाम प्राप्त करने का एक आसान तरीका होगा: केवल फेंकता घोषणा को छोड़ दें।

function first() : string { // Everything automatically inferred

जो सवाल उठाता है: टाइपस्क्रिप्ट को त्रुटियों का अनुमान लगाने के बजाय मुझे throws कीवर्ड का उपयोग करने का लाभ कब मिलेगा?

@ConnorSinnott

यह अन्य भाषाओं से अलग नहीं है जो थ्रो क्लॉज का उपयोग करती हैं, अर्थात java.
लेकिन मुझे लगता है कि ज्यादातर मामलों में आपको वास्तव में बहुत सारे प्रकारों से निपटना नहीं पड़ेगा। वास्तविक दुनिया में आप आमतौर पर केवल string , Error (और उपवर्ग) और विभिन्न वस्तुओं ( {} ) से निपटेंगे।
और ज्यादातर मामलों में आप केवल एक मूल वर्ग का उपयोग करने में सक्षम होंगे जो एक से अधिक प्रकारों को कैप्चर करता है:

type MyBaseError = {
    message: string;
};

type CodedError = MyBaseError & {
    code: number;
}

function fn1() throws MyBaseError {
    if (something) {
        throw { message: "something went wrong" };
    }
}

function fn2() throw MyBaseError {
    if (something) {
        throw { code: 2, message: "something went wrong" };
    }

    fn1();
}

जहां तक ​​संकलक द्वारा अनुमान लगाने के लिए थ्रो क्लॉज बनाम निहित रूप से उपयोग किया जाता है, मुझे लगता है कि यह टाइपस्क्रिप्ट में प्रकार घोषित करने जैसा है, कई मामलों में आपके पास नहीं है, लेकिन आप इसे अपने कोड को बेहतर ढंग से दस्तावेज करने के लिए कर सकते हैं ताकि जो कोई इसे बाद में पढ़ेगा वह इसे बेहतर ढंग से समझ सकता है।

यदि आप टाइप सुरक्षा चाहते हैं तो एक और तरीका यह है कि त्रुटियों को ला गोलंग के मूल्यों के रूप में माना जाए:
https://gist.github.com/brandonkal/06c4a9c630369979c6038fa363ec6c83
फिर भी, यह एक अच्छी सुविधा होगी।

@brandonkal
उस दृष्टिकोण पर पहले ही सूत्र में चर्चा की जा चुकी है।
यह संभव है, लेकिन ऐसा करना एक अंतर्निहित भाग/सुविधा को अनदेखा करना है जो जावास्क्रिप्ट हमें अनुमति देता है।

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

यहां कुछ शानदार विशेषताएं दी गई हैं:

1. सत्यापन कार्य एक त्रुटि नहीं फेंकेंगे:

noexcept function foo(): void {
  throw new Error('Some exception'); // <- compile error!
}

1. अनावश्यक try..catch ब्लॉक के बारे में चेतावनी:

try { // <- warning!
  foo();
} catch (e) {}

1. संकल्प हमेशा वादा:

interface ResolvedPromise<T> extends Promise<T> {
  // catch listener will never be called
  catch(onrejected?: noexcept (reason: never) => never): ResolvedPromise<T>; 

  // same apply for `.then` rejected listener,
  // resolve listener should be with `noexpect`
}

@ मोशेस्ट

अधिकांश प्रोग्रामर्स के लिए, अपवादों को फेंकना एक विरोधी पैटर्न पर विचार करता है।

मुझे लगता है कि मैं उस "अधिकांश प्रोग्रामर" समूह का हिस्सा नहीं हूं।
noexcept अच्छा है और सब कुछ है लेकिन यह इस मुद्दे के बारे में नहीं है।

यदि उपकरण हैं, तो मैं उनका उपयोग करूंगा। throw , try/catch और reject हैं, इसलिए मैं उनका उपयोग करूंगा।

यह अच्छा होगा कि उन्हें टाइपप्रति में ठीक से टाइप किया जाए।

यदि उपकरण हैं, तो मैं उनका उपयोग करूंगा। throw , try/catch और reject हैं, इसलिए मैं उनका उपयोग करूंगा।

ज़रूर। मैं उनका भी उपयोग करूंगा। मेरा कहना है, कि noexcept या throws never इस मुद्दे की एक अच्छी शुरुआत होगी।

गूंगा उदाहरण: मैं जानना चाहता हूं कि अगर मैं Math.sqrt(-2) पर कॉल करूंगा तो यह कभी भी कोई त्रुटि नहीं देगा।

वही तृतीय-पक्ष पुस्तकालयों के लिए लागू होता है। यह कोड और किनारे के मामलों पर अधिक नियंत्रण देता है जिन्हें मुझे प्रोग्रामर के रूप में संभालने की आवश्यकता होती है।

@ मोशेस्ट
लेकिन क्यों?
इस प्रस्ताव में 'अप्रत्याशित' प्रस्ताव के सभी लाभ शामिल हैं, तो कम के लिए समझौता क्यों करें?

क्योंकि इसमें उम्र लगती है (यह मुद्दा 3 साल पुराना है), और मैं उम्मीद कर रहा था कि हम कम से कम सबसे बुनियादी सुविधा के साथ शुरुआत कर सकते हैं।

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

मुझे लगता है कि बाद में noexcept को आसानी से जोड़ा जा सकता है, वास्तव में यह एक अलग विषय हो सकता है।

noexcept समान है throws never ।

टीबीएच मुझे लगता है कि try/catch के लिए प्रकार के संकेत प्रदान करने के बजाय अपवादों को संभालने की गारंटी देने वाले कुछ तंत्र होना अधिक महत्वपूर्ण है (एला ने गो में error का उपयोग नहीं किया है)

@roll कोई "गारंटी" नहीं होनी चाहिए।
जावास्क्रिप्ट में अपवादों को संभालना जरूरी नहीं है और इसे टाइपस्क्रिप्ट में भी जरूरी नहीं होना चाहिए।

यह टाइपक्रिप्ट के सख्त मोड के हिस्से के रूप में एक विकल्प हो सकता है कि किसी फ़ंक्शन को या तो त्रुटि पकड़नी चाहिए या स्पष्ट रूप से इसे throws घोषित करना चाहिए और इसे पास करना चाहिए

मेरे 5 सेंट जोड़ने के लिए: मुझे null लौटने वाले फ़ंक्शन के समान अपवाद दिखाई देते हैं: यह एक ऐसी चीज है जिसे आप सामान्य रूप से होने की उम्मीद नहीं करते हैं। लेकिन अगर ऐसा होता है तो रन-टाइम त्रुटि होती है, जो खराब है। अब, TS ने आपको null को संभालने की याद दिलाने के लिए "गैर-शून्य प्रकार" जोड़े। मुझे इन प्रयासों को एक कदम आगे ले जाने के रूप में throws को जोड़ना, आपको अपवादों को भी संभालने की याद दिलाते हुए दिखाई दे रहा है। इसलिए मुझे लगता है कि इस फीचर की जरूर जरूरत है।

यदि आप गो को देखते हैं, जो त्रुटियों को फेंकने के बजाय लौटाता है, तो आप और भी स्पष्ट देख सकते हैं कि दोनों अवधारणाएं अलग नहीं हैं। साथ ही, यह आपको कुछ एपीआई को और गहराई से समझने में मदद करता है। हो सकता है कि आप नहीं जानते कि कुछ फ़ंक्शन फेंक सकते हैं और आप इसे उत्पादन में बहुत बाद में देखते हैं (उदाहरण के लिए JSON.parse , कौन जानता है कि कितने और हैं?)

@ obedm503 यह वास्तव में TS का एक दर्शन है: डिफ़ॉल्ट रूप से संकलक किसी भी चीज़ के बारे में शिकायत नहीं करता है। आप कुछ चीजों को त्रुटि मानने के लिए विकल्पों को सक्षम कर सकते हैं या सभी विकल्पों को एक साथ सक्षम करने के लिए सख्त मोड सक्षम कर सकते हैं। तो, यह एक दिया जाना चाहिए।

मुझे यह सुझाई गई विशेषता पसंद है।
अपवाद टाइपिंग और अनुमान पूरे प्रोग्रामिंग इतिहास में सबसे अच्छी चीजों में से एक हो सकता है।
❤️

हैलो, मैंने टीएस में वर्तमान में जो कुछ भी किया है, उसके साथ वर्कअराउंड खोजने का प्रयास करने में मैंने अभी थोड़ा समय बिताया है। चूंकि फ़ंक्शन स्कोप के भीतर फेंकने वाली त्रुटियों के प्रकार को प्राप्त करने का कोई तरीका नहीं है (न ही वर्तमान विधि के प्रकार को प्राप्त करने के लिए) मुझे पता चला कि हम विधि के भीतर अपेक्षित त्रुटियों को स्पष्ट रूप से कैसे सेट कर सकते हैं। हम बाद में, उन प्रकारों को पुनः प्राप्त कर सकते हैं और कम से कम यह जान सकते हैं कि विधि के भीतर क्या फेंका जा सकता है।

यहाँ मेरा पीओसी है

/***********************************************
 ** The part to hide a type within another type
 **********************************************/
// A symbol to hide the type without colliding with another existing type
const extraType = Symbol("A property only there to store types");

type extraType<T> = {
    [extraType]?: T;
}

// Set an extra type to any other type
type extraTyped<T, E> = T & extraType<E>

// Get back this extra type
type getExtraType<T> = T extends extraType<infer T> ? T : never;

/***********************************************
 ** The part to implement a throwable logic
 **********************************************/

// Throwable is only a type holding the possible errors which can be thrown
type throwable<T, E extends Error> = extraTyped<T,E>

// return the error typed according to the throwableMethod passed into parameter
type basicFunction = (...any: any[]) => any;
const getTypedError = function<T extends basicFunction> (error, throwableMethod:T) {
    return error as getExtraType<ReturnType<T>>;
};

/***********************************************
 ** An example of usage
 **********************************************/

class CustomError extends Error {

}

// Here is my unreliable method which can crash throwing Error or CustomError.
// The returned type is simply our custom type with what we expect as the first argument and the
// possible thrown errors types as the second (in our case a type union of Error and CustomError)
function unreliableNumberGenerator(): throwable<number, Error | CustomError> {

    if (Math.random() > 0.5) {
        return 42;
    }

    if (Math.random() > 0.5) {
        new Error('No luck');
    }

    throw new CustomError('Really no luck')
}

// Usage
try {
    let myNumber = unreliableNumberGenerator();
    myNumber + 23;
}

// We cannot type error (see TS1196)
catch (error) {
    // Therefore we redeclare a typed value here and we must tell the method which could have crashed
    const typedError = getTypedError(error, unreliableNumberGenerator);

    // 2 possible usages:
    // Using if - else clauses
    if (typedError instanceof CustomError) {

    }

    if (typedError instanceof Error) {

    }

    // Or using a switch case on the constructor:
    // Note: it would have been really cool if TS did understood the typedError.constructor is narrowed by the types Error | CustomError
    switch (typedError.constructor) {
        case Error: ;
        case CustomError: ;
    }

}

// For now it is half a solution as the switch case is not narrowing anything. This would have been 
// possible if the typedError would have been a string union however it would not be reliable to rely
// on typedError.constructor.name (considering I would have find a way to convert the type union to a string union)

आपकी सकारात्मक प्रतिक्रिया के लिए बहुत-बहुत धन्यवाद! मुझे एहसास है कि पूरे लौटा प्रकार को throwable प्रकार में लपेटे बिना मौजूदा कोड को दोबारा करना आसान हो सकता है। इसके बजाय हम केवल उस एक को लौटाए गए प्रकार में जोड़ सकते हैं, निम्न कोड आपको फेंकने योग्य त्रुटियों को निम्नानुसार जोड़ने देता है:

// now only append '& throwable<ErrorsThrown>' to the returned type
function unreliableNumberGenerator(): number & throwable<Error | CustomError> { /* code */ }

उदाहरण भाग के लिए यह एकमात्र परिवर्तन है, यहाँ नए प्रकार की घोषणा है:

/***********************************************
 ** The part to hide a type within another type
 **********************************************/
// A symbol to hide the type without colliding with another existing type
const extraType = Symbol("A property only there to store types");

type extraType<T> = {
    [extraType]?: T;
}

// Get back this extra type
type getExtraType<T> = T extends extraType<infer T> ? T : never;

/***********************************************
 ** The part to implement a throwable logic
 **********************************************/

// Throwable is only a type holding the possible errors which can be thrown
type throwable<E extends Error> = extraType<E>

// return the error typed according to the throwableMethod passed into parameter
type basicFunction = (...any: any[]) => any;

type exceptionsOf<T extends basicFunction> = getExtraType<ReturnType<T>>;

const getTypedError = function<T extends basicFunction> (error: unknown, throwableMethod:T) {
    return error as exceptionsOf<T>;
};

मैंने एक नया प्रकार exceptionsOf भी जोड़ा है जो जिम्मेदारी को बढ़ाने के लिए किसी फ़ंक्शन की त्रुटियों को निकालने की अनुमति देता है। उदाहरण के लिए:

function anotherUnreliableNumberGenerator(): number & throwable<exceptionsOf<typeof unreliableNumberGenerator>> {
// I don't want to use a try and catch block here
    return (Math.random() > 0.5) ? unreliableNumberGenerator() : 100;
}

जैसे ही exceptionsOf को त्रुटियों का एक संघ मिलता है, आप जितनी चाहें उतनी महत्वपूर्ण विधि को आगे बढ़ा सकते हैं:

function aSuperUnreliableNumberGenerator(): number & throwable<exceptionsOf<typeof unreliableNumberGenerator> | exceptionsOf<typeof anotherUnreliableNumberGenerator>> {
// I don't want to use a try and catch block here
    return (Math.random() > 0.5) ? unreliableNumberGenerator() : unreliableNumberGenerator();
}

मुझे typeof का उपयोग पसंद नहीं है, अगर मुझे कोई बेहतर तरीका मिल जाए तो मैं आपको बता दूंगा

आप यहां परिणाम युक्तियों का परीक्षण कर सकते हैं : typedError लाइन 106 . पर होवर करें

@Xample यह हमारे पास अभी मौजूद टूल के साथ एक अच्छा समाधान है!
लेकिन मुझे लगता है कि व्यवहार में यह पर्याप्त नहीं है क्योंकि आप अभी भी इस तरह की चीजें कर सकते हैं:

const a = superRiskyMethod();
const b = a + 1;

और बी के प्रकार को संख्या के रूप में अनुमानित किया जाता है जो सही है लेकिन अगर यह एक कोशिश के अंदर लपेटा गया है
यह मान्य नहीं होना चाहिए

@luisgurmendezMLabs मुझे वह नहीं मिलता जो आपका मतलब है। यदि आप लाइन 56 पर @Xample के रेपो का अनुसरण करते हैं। आप देख सकते हैं कि myNumber + 23 number रूप में अनुमानित है, जबकि myNumber: number & extraType<Error | CustomError> ।

दूसरे चरण में, a आपके उदाहरण में कभी भी कोशिश मोनाड जैसी किसी चीज़ में लपेटा नहीं जाता है। इसमें & extraType<Error | CustomError> वाले चौराहे के अलावा कोई रैपर नहीं है।

शानदार डिज़ाइन @Xample के लिए बधाई। यह वास्तव में आशाजनक है, और बिना किसी वाक्यात्मक चीनी के भी पहले से ही उपयोगी है। क्या आपके पास इसके लिए टाइप लाइब्रेरी बनाने की कोई योजना है?

@ivawzh मेरे विचार हैं कि व्यवहार में यह कुछ मुद्दों को ला सकता है:

function stillARiskyMethod() { 
    const a = superRiskyMethod();
    return a + 1
}

वह फ़ंक्शन प्रकार वापसी संख्या के रूप में अनुमानित है और यह पूरी तरह से सही नहीं है

@luisgurmendezMLabs फेंकने योग्य प्रकार फ़ंक्शन के रिटर्न प्रकार के भीतर केवल फ़ंक्शन के साथ त्रुटि के प्रकार को चिपकाने के तरीके के रूप में होता है (और बाद में उन प्रकारों को पुनर्प्राप्त करने में सक्षम होने के लिए)। मैं वास्तविक के लिए त्रुटियों को कभी नहीं लौटाता, मैं केवल उन्हें फेंक देता हूं। इसलिए यदि आप एक कोशिश ब्लॉक में हैं या नहीं तो कुछ भी नहीं बदलेगा।

@ivawzh पूछने के लिए धन्यवाद, मैंने अभी आपके लिए किया है

@luisgurmendezMLabs आह ठीक है, मैं आपकी बात समझता हूं, ऐसा लगता है कि टाइपस्क्रिप्ट केवल पहले प्रकार का अनुमान लगाता है। उदाहरण के लिए यदि आपके पास था:

function stillARiskyMethod() { 
    return superRiskyMethod();
}

स्टिलARiskyMethod का रिटर्न प्रकार सही ढंग से अनुमान लगाया जाएगा, जबकि

function stillARiskyMethod() { 
    return Math.random() < 0.5 superRiskyMethod() : anotherSuperRiskyMethod();
}

केवल वापसी प्रकार को superRiskyMethod() के रूप में टाइप करेगा और anotherSuperRiskyMethod() में से किसी एक को खारिज कर देगा। मैंने अधिक जांच नहीं की है

इस कारण से, आपको त्रुटि प्रकार को मैन्युअल रूप से बढ़ाना होगा।

function stillARiskyMethod(): number & throwable<exceptionOf<typeof superRiskyMethod>> { 
    const a = superRiskyMethod();
    return a + 1
}

मैं भी बस इस पर अपने विचार रखना चाहता था।

मुझे लगता है कि यह लागू करने के लिए वास्तव में एक अच्छी सुविधा होगी क्योंकि त्रुटि/शून्य वापस करने और कुछ फेंकने की इच्छा रखने के लिए अलग-अलग उपयोग के मामले हैं और इसमें बहुत अधिक संभावनाएं हो सकती हैं। अपवाद फेंकना वैसे भी जावास्क्रिप्ट भाषा का हिस्सा है, तो हमें इन्हें टाइप करने और अनुमान लगाने का विकल्प क्यों नहीं देना चाहिए?

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

यह विशेष रूप से तब उपयोगी होता है जब आप त्रुटि को उसी तरह से संभालने जा रहे हों ; उदाहरण के लिए एक्सप्रेस/नोड.जेएस में, मैं त्रुटि को NextFunction (त्रुटि हैंडलर) में पास करना चाह सकता हूं।

हर बार if (result instanceof Error) { next(result); } करने के बजाय, मैं इन कार्यों के लिए सभी कोड को एक कोशिश/पकड़ में लपेट सकता हूं, और मेरे पकड़ में मुझे पता है कि एक अपवाद फेंक दिया गया था, मैं हमेशा इसे अपने पास करना चाहता हूं त्रुटि हैंडलर, तो catch(error) { next(error); } . कर सकते हैं

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

संपादित करें: एक और उपयोग-मामला जिसके बारे में मैंने सोचा था कि यह @throws टैग का उपयोग करके JSDocs की पीढ़ी में भी मदद करेगा

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

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

function a() {
  if (Math.random() > .5) {
    throw 'unlucky';
  }
}

function b() {
  a();
}

function c() {
  if (Math.random() > .5) {
    throw 'unlucky';
  }
  if (Math.random() > .5) {
    throw 'fairly lucky';
  }
}

function d() {
  return eval('You have no IDEA what I am capable of!');
}

function e() {
  try {
    return c;
  } catch(e) {
    throw 'too bad...';
  }
}

function f() {
  c();
}

function g() {
  a();
  c();
}

• फ़ंक्शन a हम जानते हैं कि त्रुटि प्रकार 'unlucky' है, और यदि हम बहुत सतर्क रहना चाहते हैं तो हम इसे Error | 'unlucky' तक बढ़ा सकते हैं, इसलिए includeError ।
• फ़ंक्शन b त्रुटि प्रकार के फ़ंक्शन a $ को इनहेरिट करेगा।
• समारोह c लगभग समान है; 'unlucky' | 'fairly lucky' , या Error | 'unlucky' | 'fairly lucky' ।
• समारोह d को फेंकना होगा unknown , जैसा कि eval है... अज्ञात
• फ़ंक्शन e d की त्रुटि को पकड़ता है, फिर भी चूंकि कैच ब्लॉक में throw है, इसलिए हम इसके प्रकार का अनुमान लगाते हैं 'too bad...' , यहां, केवल ब्लॉक के बाद से इसमें throw 'primitive value' शामिल है, हम कह सकते हैं कि यह Error नहीं फेंक सकता (अगर मुझे कुछ JS काला जादू छूट गया हो तो मुझे सुधारें ...)
• फ़ंक्शन f c से विरासत में मिला है, जैसा कि b ने a से किया था।
• समारोह g को 'unlucky' से a और unknown से c इस प्रकार 'unlucky' | unknown => unknown $ विरासत में मिला है

यहां कुछ कंपाइलर विकल्प दिए गए हैं जो मुझे लगता है कि शामिल किए जाने चाहिए, क्योंकि इस सुविधा के साथ उपयोगकर्ता जुड़ाव उनके कौशल के साथ-साथ पुस्तकालयों की प्रकार-सुरक्षा के आधार पर भिन्न हो सकते हैं जो वे दिए गए प्रोजेक्ट पर निर्भर करते हैं:

{
  "compilerOptions": {
    "errorHandelig": {
      "enable": true,
      "forceCatching": false,   // Maybe better suited for TSLint/ESLint...
      "includeError": true, // If true, every function will by default throw `Error | (types of throw expressions)`
      "catchUnknownOnly": false, // If true, every function will by default throw `unknown`, for those very skeptics (If someone replaces some global with weird proxy, for example...)
      "errorAsesertion": true,  // If false, the user will not be able to change error type manually
    }
  }
}

त्रुटि को व्यक्त करने के तरीके पर सिंटैक्स के लिए कोई फ़ंक्शन उत्पन्न कर सकता है, मुझे यकीन नहीं है, लेकिन मुझे पता है कि हमें सामान्य और अनुमानित होने की क्षमता की आवश्यकता है।

declare function getValue<T extends {}, K extends keyof T>(obj: T, key: K): T[K] throws void;
declare function readFile<throws E = 'not valid file'>(file: string, customError: E): string throws E;

मेरा उपयोग-मामला, वास्तविक उपयोग-मामला दिखाने के रूप में अन्य दिखा सकता है कि इसका एक मूल्य है:

declare function query<T extends {}, throws E>(sql: string, error: E): T[] throws E;

app.get('path',(req, res) => {
  let user: User;
  try {
    user = query('SELECT * FROM ...', 'get user');
  } catch(e) {
    return res.status(401);
  }

  try {
    const [posts, followers] = Promise.all([
      query('SELECT * FROM ...', "user's posts"),
      query('SELECT * FROM ...', "user's follower"'),
    ]);

    res.send({ posts, followers });
  } catch(e) {
    switch (e) {
      case "user's posts":
        return res.status(500).send('Loading of user posts failed');

      case "user's posts":
        return res.status(500).send('Loading of user stalkers failed, thankfully...');

      default:
        return res.status(500).send('Very strange error!');
    }
  }
});

एकाधिक त्रुटियों के लिए प्रतिक्रिया के शीर्षलेख कई बार भेजने से रोकने के लिए मुझे एक त्रुटि सिंक की आवश्यकता है (वे आमतौर पर नहीं होते हैं, लेकिन जब वे ऐसा करते हैं तो वे थोक में ऐसा करते हैं!)

इस मुद्दे को अभी भी Awaiting More Feedback टैग किया गया है, हम और प्रतिक्रिया प्रदान करने के लिए क्या कर सकते हैं? यह एकमात्र विशेषता है जिसे मैं जावा भाषा से ईर्ष्या करता हूं

हमारे पास एक उपयोग का मामला है जहां हम एक विशिष्ट त्रुटि फेंकते हैं जब कोई एपीआई कॉल गैर -200 कोड लौटाता है:

interface HttpError extends Error {
  response: Response
}

try {
  loadData()
} catch (error: Error | ResponseError) {
  if (error.response) {
    checkStatusCodeAndDoSomethingElse()
  } else {
    doGenericErrorHandling()
  }
}

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

मैं हमेशा त्रुटि वस्तु फेंकना पसंद करता हूं:

function fn(num: number): void {
    if (num === 0) {
        throw new TypeError("Can't deal with 0")
    }
}
try {
 fn(0)
}
catch (err) {
  if (err instanceof TypeError) {
   if (err.message.includes('with 0')) { .....}
  }
}

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

ऐसा लगता है कि हेगेल में यह सुविधा पूरी तरह से है।
https://hegel.js.org/docs#benefits ("टाइप की गई त्रुटि" अनुभाग तक स्क्रॉल करें)

काश टाइपस्क्रिप्ट में भी ऐसी ही विशेषता होती!

डीएल; डॉ;

• वादों का अस्वीकार कार्य टाइप किया जाना चाहिए
• try ब्लॉक के भीतर फेंके गए किसी भी प्रकार को catch के त्रुटि तर्क में एक संघ का उपयोग करके अनुमान लगाया जाना चाहिए
• error.constructor को वास्तविक प्रकार का उपयोग करके ठीक से टाइप किया जाना चाहिए और न केवल any एक फेंकी गई त्रुटि को रोकने के लिए।

ठीक है, शायद हमें यह स्पष्ट करना चाहिए कि हमारी ज़रूरतें और अपेक्षाएँ क्या हैं:

त्रुटियों को आमतौर पर js . में 3 तरीकों से नियंत्रित किया जाता है

1. नोड रास्ता

कॉलबैक का उपयोग करना (जिसे वास्तव में टाइप किया जा सकता है)

उपयोग का उदाहरण:

import * as fs from 'fs';

fs.readFile('readme.txt', 'utf8',(error, data) => {
    if (error){
        console.error(error);
    }
    if (data){
        console.log(data)
    }
});

जहां fs.d.ts हमें देता है:

function readFile(path: PathLike | number, options: { encoding: string; flag?: string; } | string, callback: (err: NodeJS.ErrnoException | null, data: string) => void): void;

इसलिए त्रुटि इस प्रकार टाइप की गई है

    interface ErrnoException extends Error {
        errno?: number;
        code?: string;
        path?: string;
        syscall?: string;
        stack?: string;
    }

2. वादा तरीका

जहां वादा या तो हल करता है या अस्वीकार करता है, जबकि आप हल किए गए value टाइप कर सकते हैं, आप अस्वीकृति टाइप नहीं कर सकते हैं जिसे अक्सर reason कहा जाता है।

यहां एक वादे के निर्माता के हस्ताक्षर हैं: ध्यान दें कि कारण any . टाइप किया गया है

    new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

सैद्धांतिक रूप से उन्हें निम्नानुसार टाइप करना संभव हो सकता था:

    new <T, U=any>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: U) => void) => void): Promise<T>;

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

const fs = require('fs')
const util = require('util')

const readFilePromise = util.promisify(fs.readFile); // (path: PathLike | number, options: { encoding: string; flag?: string; } | string) => Promise<data: string, NodeJS.ErrnoException>;

3. "कोशिश करो और पकड़ो" तरीका

try {
    throw new Error();
}
catch (error: unknown) { //typing the error is possible since ts 4.0
    if (error instanceof Error) {
        error.message;
    }
}

कैच ब्लॉक से पहले हम एक त्रुटि "त्रुटि" 2 लाइन फेंक रहे हैं, TS error (मान) को Error (प्रकार) के रूप में टाइप करने में असमर्थ है।

क्या यह मामला नहीं है और न ही async फ़ंक्शन के भीतर वादों का उपयोग करना ("अभी तक कोई जादू नहीं है")। हमारे वादा किए गए नोड कॉलबैक का उपयोग करना:

async function Example() {
    try {
        const data: string = await readFilePromise('readme.txt', 'utf-8');
        console.log(data)
    }
    catch (error) { // it can only be NodeJS.ErrnoException, we can type is ourself… but nothing prevents us to make a mistake
        console.error(error.message);
    }
}

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

यह केवल पहला कदम है और अभी भी सुधार के लिए जगह होगी, जैसे कि एक सख्त मोड टीएस को जावा में काम करने के लिए मजबूर करता है यानी उपयोगकर्ता को try के भीतर एक जोखिम भरा तरीका (एक विधि जो कुछ फेंक सकता है) का उपयोग करने के लिए मजबूर करता है। function example throw ErrorType { ... } के रूप में चिह्नित करेगा।

अंतिम लेकिन कम से कम नहीं: एक त्रुटि चूकने से रोकें

कुछ भी फेंका जा सकता है, न केवल एक त्रुटि या किसी वस्तु का एक उदाहरण। मतलब निम्नलिखित मान्य है

try {
    if (Math.random() > 0.5) {
        throw 0
    } else {
        throw new Error()
    }
}
catch (error) { // error can be a number or an object of type Error
    if (typeof error === "number") {
        alert("silly number")
    }

    if (error instanceof Error) {
        alert("error")
    }
}

यह जानने के लिए कि त्रुटि number | Error प्रकार की हो सकती है, अविश्वसनीय रूप से सहायक होगी। हालांकि संभावित प्रकार की त्रुटि को संभालने के लिए भूलने से रोकने के लिए संभावित परिणामों के सख्त सेट के बिना अलग/अन्य ब्लॉक का उपयोग करना वास्तव में सबसे अच्छा विचार नहीं है।
एक स्विच केस हालांकि यह बहुत बेहतर करेगा क्योंकि हमें चेतावनी दी जा सकती है अगर हम किसी विशिष्ट मामले से मिलान करना भूल गए (जो कि डिफ़ॉल्ट क्लॉज पर वापस आ जाएगा)। हम (जब तक हम कुछ हैकिश नहीं करते) केस को ऑब्जेक्ट इंस्टेंस प्रकार स्विच नहीं कर सकते हैं, और यहां तक ​​​​कि अगर हम कर सकते हैं, तो हम कुछ भी फेंक सकते हैं (न केवल एक वस्तु बल्कि एक बूलियन, एक स्ट्रिंग और एक संख्या जिसका कोई "इंस्टेंस" नहीं है)। हालाँकि, हम इंस्टेंस के कंस्ट्रक्टर का उपयोग यह पता लगाने के लिए कर सकते हैं कि यह किस प्रकार का है। अब हम ऊपर दिए गए कोड को निम्नानुसार फिर से लिख सकते हैं:

try {
    if (Math.random() > 0.5) {
        throw 0
    } else {
        throw new Error()
    }
}
catch (error) { // error can be a Number or an object of type `Error`
    switch (error.constructor){
        case Number: alert("silly number"); break;
        case Error: alert("error"); break;
    }
}

होरे… एकमात्र शेष समस्या यह है कि TS error.constructor टाइप नहीं करता है और इसलिए स्विच केस को संकीर्ण करने का कोई तरीका नहीं है (अभी तक?), अगर ऐसा होता है, तो हमारे पास एक सुरक्षित टाइप की गई त्रुटि भाषा होगी जेएस

कृपया टिप्पणी करें यदि आपको अधिक प्रतिक्रिया की आवश्यकता है