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

त्रुटि प्रबंधन

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

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

fn failingFunction() error{MyError}!void {
    return error.MyError;
}

pub fn main() !void {
    try failingFunction();
}

उपरोक्त कोड में हम एक त्रुटि MyError घोषित करते हैं (यह अलग से भी किया जा सकता है) और इसे वापस कर देते हैं।
प्रयास का अर्थ है "यदि यह कोई त्रुटि लौटाता है, तो इसे यहां लौटाएं" जैसा कि:

failingFunction() catch |err| return err;

मेरा मानना ​​​​है कि यह दृष्टिकोण एक महान संयोजन है और हमें गो भूमि में अंतहीन अगर (त्रुटि! = शून्य) से बचाता है।

अन्य मुख्य आकर्षण:

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

!void सिंटेक्स - ! रिटर्न प्रकार और त्रुटि प्रकारों के बीच एक संघ बनाने के लिए उपयोग किया जाता है। ज़िग! से पहले कोई भी त्रुटि न जोड़ने का समर्थन करता है, जो उन सभी त्रुटियों का एक संघ बनाता है जो आप वास्तव में फ़ंक्शन से लौटाते हैं।

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

पेलोड कैप्चरिंग

आप जानते हैं कि टीएस में आपके पास संख्या जैसा प्रकार कैसे हो सकता है | अपरिभाषित? आप जिस प्रकार की आवश्यकता है उसे सीमित करने के लिए आप if या कुछ तर्क का उपयोग कर सकते हैं, और TS स्वचालित रूप से नए प्रकार को सही ढंग से प्रदर्शित करता है।
हालाँकि यह आसान है, इस दृष्टिकोण में समस्याएँ भी हैं:

• यदि पूरे फ़ंक्शन में प्रकार बदल सकते हैं, तो इसका पालन करना कठिन है
• कुछ मामलों में आपको अभी भी कास्ट करना होगा

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

const maybe_num: ?usize = 10; // `?` Means it can be `null`

if (maybe_num) |num| {
    // Use num
}

यह बिल्कुल स्पष्ट है कि क्या हो रहा है! इसके अलावा, वेरिएबल अपरिवर्तनीय है, लेकिन यदि आपको वास्तव में इसे बदलने की आवश्यकता है, तो आप इसके बजाय मान पर एक पॉइंटर कैप्चर कर सकते हैं।

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

कॉम्पटाइम षडयंत्र

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

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

ज़िग गाइड से इसका एक बुनियादी उदाहरण:

const a = 5; // When a number type isn't specified, it defaults to comptime_int
const b: if (a 




  
  
  संपादक का अनुभव


मैं आधिकारिक Zig प्लगइन (जो zls का उपयोग करता है) के साथ VSCode का उपयोग कर रहा हूं। संपादक में मुझे जो बुद्धिमत्ता और त्रुटियाँ दिखाई देती हैं, उनमें बहुत कुछ वांछित नहीं है।

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



const nums = [3]u8{ 2, 1, 3 };
_ = nums[4]; // Index out of bounds error




मैं 0.14 (डेव) मास्टर ब्रांच संस्करण पर हूं, अगर यह काम करेगा तो मुझे टिप्पणियों में बताएं!