VBA के लिए पठनीय कोड लिखना - कोशिश करें* पैटर्न

हाल ही में, मैं Try . का उपयोग करके खुद को ढूंढ रहा हूं अधिक से अधिक पैटर्न। मुझे वास्तव में यह पैटर्न पसंद है क्योंकि यह बहुत अधिक पठनीय कोड बनाता है। यह विशेष रूप से महत्वपूर्ण है जब वीबीए जैसी परिपक्व प्रोग्रामिंग भाषा में प्रोग्रामिंग की जाती है जहां त्रुटि प्रबंधन नियंत्रण प्रवाह के साथ जुड़ा हुआ है। आम तौर पर, मुझे ऐसी कोई भी प्रक्रिया मिलती है जो नियंत्रण प्रवाह के रूप में त्रुटि प्रबंधन पर निर्भर करती है, जिसका पालन करना कठिन होता है।

परिदृश्य

आइए एक उदाहरण से शुरू करते हैं। डीएओ ऑब्जेक्ट मॉडल एक आदर्श उम्मीदवार है क्योंकि यह कैसे काम करता है। देखिए, सभी DAO ऑब्जेक्ट्स में Properties होते हैं संग्रह, जिसमें Property . शामिल है वस्तुओं। हालांकि, कोई भी कस्टम प्रॉपर्टी जोड़ने में सक्षम है। वास्तव में, एक्सेस विभिन्न डीएओ ऑब्जेक्ट्स में कई गुण जोड़ देगा। इसलिए, हमारे पास एक ऐसी संपत्ति हो सकती है जो मौजूद नहीं हो सकती है और मौजूदा संपत्ति के मूल्य को बदलने और एक नई संपत्ति को जोड़ने के मामले दोनों को संभालना चाहिए।

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

Public Sub EditTableSubdatasheetProperty( _
    Optional NewValue As String = "[None]" _
)
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim prp As DAO.Property
    Const SubDatasheetPropertyName As String = "SubdatasheetName"
    
    On Error GoTo ErrHandler

    Set db = CurrentDb
    For Each tdf In db.TableDefs
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If Len(tdf.Connect) = 0 And (Not tdf.Name Like "~*") Then 'Not attached, or temp.
                Set prp = tdf.Properties(SubDatasheetPropertyName)
                If prp.Value <> NewValue Then
                    prp.Value = NewValue
                End If
            End If
        End If
Continue:
    Next

ExitProc:
    Exit Sub

ErrHandler:
    If Err.Number = 3270 Then
        Set prp = tdf.CreateProperty(SubDatasheetPropertyName , dbText, NewValue)
        tdf.Properties.Append prp
        Resume Continue    
    End If
    
    MsgBox Err.Number & ": " & Err.Description
    Resume ExitProc    
End Sub

कोड शायद काम करेगा। हालाँकि, इसे समझने के लिए, हमें शायद कुछ फ्लो चार्ट को आरेखित करना होगा। लाइन Set prp = tdf.Properties(SubDatasheetPropertyName) संभावित रूप से एक त्रुटि 3270 फेंक सकता है। इस स्थिति में, नियंत्रण त्रुटि प्रबंधन अनुभाग में कूद जाता है। फिर हम एक प्रॉपर्टी बनाते हैं और फिर लूप के एक अलग बिंदु पर Continue . लेबल का उपयोग करके फिर से शुरू करते हैं . कुछ सवाल हैं...

• क्या होगा अगर 3270 को किसी दूसरी लाइन पर उठाया जाए?
• मान लीजिए कि लाइन Set prp =... फेंकता नहीं त्रुटि 3270 लेकिन वास्तव में कुछ अन्य त्रुटि?
• क्या होगा यदि जब हम एरर हैंडलर के अंदर होते हैं, तो Append . को निष्पादित करते समय एक और त्रुटि होती है या CreateProperty ?
• क्या यह फ़ंक्शन Msgbox भी दिखा रहा होगा? ? उन कार्यों के बारे में सोचें जो फ़ॉर्म या बटन की ओर से किसी चीज़ पर काम करने वाले हैं। यदि फ़ंक्शन एक संदेश बॉक्स दिखाते हैं, तो सामान्य रूप से बाहर निकलें, कॉलिंग कोड को पता नहीं है कि कुछ गलत हो गया है और वह ऐसे काम करना जारी रख सकता है जो उसे नहीं करना चाहिए।
• क्या आप कोड पर एक नज़र डाल सकते हैं और समझ सकते हैं कि यह तुरंत क्या करता है? मैं नहीं कर सकता। मुझे इस पर ध्यान देना है, फिर सोचें कि त्रुटि के मामले में क्या होना चाहिए और मानसिक रूप से पथ को स्केच करें। इसे पढ़ना आसान नहीं है।

एक HasPropertyजोड़ें प्रक्रिया

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

Public Sub EditTableSubdatasheetProperty( _
    Optional NewValue As String = "[None]" _
)
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim prp As DAO.Property
    Const SubDatasheetPropertyName As String = "SubdatasheetName"
    
    Set db = CurrentDb
    For Each tdf In db.TableDefs
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If Len(tdf.Connect) = 0 And (Not tdf.Name Like "~*") Then 'Not attached, or temp.
                If Not HasProperty(tdf, SubDatasheetPropertyName) Then
                    Set prp = tdf.CreateProperty(SubDatasheetPropertyName , dbText, NewValue)
                    tdf.Properties.Append prp
                Else
                    If tdf.Properties(SubDatasheetPropertyName) <> NewValue Then
                        tdf.Properties(SubDatasheetPropertyName) = NewValue
                    End If
                End If
            End If
        End If
    Next
End Sub

Public Function HasProperty(TargetObject As Object, PropertyName As String) As Boolean
    Dim Ignored As Variant
    
    On Error Resume Next
    Ignored = TargetObject.Properties(PropertyName)
    HasProperty = (Err.Number = 0)
End Function

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

• हमारी एक शाखा है जो चर prp . का उपयोग करती है और हमारे पास एक और शाखा है जो tdf.Properties(SubDatasheetPropertyName) का उपयोग करती है जो वास्तव में उसी संपत्ति को संदर्भित करता है। हम एक ही संपत्ति को संदर्भित करने के लिए दो अलग-अलग तरीकों से खुद को क्यों दोहरा रहे हैं?
• हम संपत्ति को काफी संभाल रहे हैं। HasProperty यह पता लगाने के लिए संपत्ति को संभालना है कि यह मौजूद है या नहीं, तो बस एक Boolean लौटाता है परिणाम, इसे फिर से कोशिश करने के लिए कॉलिंग कोड पर छोड़ देना और मूल्य बदलने के लिए फिर से वही संपत्ति प्राप्त करना।
• इसी तरह, हम NewValue . को संभाल रहे हैं आवश्यकता से अधिक। हम या तो इसे CreateProperty . में पास करते हैं या Value सेट करें संपत्ति की संपत्ति।
• द HasProperty फ़ंक्शन परोक्ष रूप से मानता है कि ऑब्जेक्ट में Properties है सदस्य और इसे लेट-बाउंड कहते हैं, जिसका अर्थ है कि यदि इसे गलत प्रकार की वस्तु प्रदान की जाती है तो यह एक रनटाइम त्रुटि है।

TryGetProperty का उपयोग करें इसके बजाय

क्या हम बेहतर कर सकते हैं? हां! यहीं पर हमें ट्राई पैटर्न को देखने की जरूरत है। यदि आपने कभी .NET के साथ प्रोग्राम किया है, तो संभवतः आपने TryParse जैसे तरीके देखे होंगे जहां हम असफलता पर गलती करने के बजाय सफलता के लिए कुछ और असफलता के लिए कुछ और करने की शर्त रख सकते हैं। लेकिन इससे भी महत्वपूर्ण बात यह है कि हमारे पास सफलता के लिए उपलब्ध परिणाम है। तो हम HasProperty . पर कैसे सुधार करेंगे समारोह? एक बात के लिए, हमें Property को वापस करना चाहिए वस्तु। आइए इस कोड को आजमाएं:

Public Function TryGetProperty( _
    ByVal SourceProperties As DAO.Properties, _
    ByVal PropertyName As String, _
    ByRef OutProperty As DAO.Property _
) As Boolean 
    On Error Resume Next
    Set OutProperty = SourceProperties(PropertyName)
    If Err.Number Then
        Set OutProperty = Nothing
    End If
    On Error GoTo 0

    TryGetProperty = (Not OutProperty Is Nothing)
End Function

कुछ बदलावों के साथ, हमने कुछ बड़ी जीत हासिल की हैं:

• Properties तक पहुंच अब लेट-बाउंड नहीं है। हमें यह आशा करने की आवश्यकता नहीं है कि किसी वस्तु में Properties . नाम की संपत्ति हो और यह DAO.Properties . का है . इसे संकलन-समय पर सत्यापित किया जा सकता है।
• सिर्फ एक Boolean के बजाय परिणाम, हम पुनः प्राप्त Property . भी प्राप्त कर सकते हैं विरोध, लेकिन केवल सफलता पर। यदि हम विफल हो जाते हैं, तो OutProperty पैरामीटर होगा Nothing . हम अब भी Boolean . का उपयोग करेंगे जैसा कि आप शीघ्र ही देखेंगे, अप फ्लो सेट करने में सहायता के लिए परिणाम।
• हमारे नए फ़ंक्शन को Try . के साथ नाम देकर उपसर्ग, हम संकेत कर रहे हैं कि यह सामान्य परिचालन स्थितियों के तहत त्रुटि नहीं फेंकने की गारंटी है। जाहिर है, हम स्मृति त्रुटियों या ऐसा कुछ नहीं रोक सकते हैं, लेकिन उस समय, हमारे पास बहुत बड़ी समस्याएं हैं। लेकिन सामान्य परिचालन स्थिति के तहत, हमने निष्पादन प्रवाह के साथ अपनी त्रुटि प्रबंधन को उलझाने से बचा लिया है। कोड को अब बिना आगे या पीछे कूदे ऊपर से नीचे तक पढ़ा जा सकता है।

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

संशोधित कॉलिंग कोड TryGetProperty . का उपयोग करके

Public Sub EditTableSubdatasheetProperty( _
    Optional NewValue As String = "[None]" _
)
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim prp As DAO.Property
    Const SubDatasheetPropertyName As String = "SubdatasheetName"
    
    Set db = CurrentDb
    For Each tdf In db.TableDefs
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If Len(tdf.Connect) = 0 And (Not tdf.Name Like "~*") Then 'Not attached, or temp.
                If TryGetProperty(tdf, SubDatasheetPropertyName, prp) Then
                    If prp.Value <> NewValue Then
                        prp.Value = NewValue
                    End If
                Else
                    Set prp = tdf.CreateProperty(SubDatasheetPropertyName , dbText, NewValue)
                    tdf.Properties.Append prp
                End If
            End If
        End If
    Next
End Sub

पहले प्रयास पैटर्न के साथ कोड अब थोड़ा अधिक पठनीय है। हमने prp . की हैंडलिंग को कम करने में कामयाबी हासिल की है . ध्यान दें कि हम prp . पास करते हैं true लौटाता है , prp उस संपत्ति के साथ आरंभ किया जाएगा जिसे हम हेरफेर करना चाहते हैं। अन्यथा, prp रहता है Nothing . इसके बाद हम CreateProperty . का उपयोग कर सकते हैं prp को इनिशियलाइज़ करने के लिए चर।

हमने नकार को भी फ़्लिप किया ताकि कोड को पढ़ना आसान हो जाए। हालांकि, हमने वास्तव में NewValue . की हैंडलिंग को कम नहीं किया है पैरामीटर। मूल्य की जांच करने के लिए हमारे पास अभी भी एक और नेस्टेड ब्लॉक है। क्या हम बेहतर कर सकते हैं? हां! आइए एक और फ़ंक्शन जोड़ें:

TrySetPropertyValue जोड़ना प्रक्रिया

Public Function TrySetPropertyValue( _
    ByVal SourceProperty As DAO.Property, _
    ByVal NewValue As Variant_
) As Boolean 
    If SourceProperty.Value = PropertyValue Then
        TrySetPropertyValue = True
    Else
        On Error Resume Next
        SourceProperty.Value = NewValue
        On Error GoTo 0
        TrySetPropertyValue = (SourceProperty.Value = NewValue)
    End If
End Function

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

अपडेट किया गया कॉलिंग कोड TryGetProperty दोनों का उपयोग कर रहा है और TrySetPropertyValue

Public Sub EditTableSubdatasheetProperty( _
    Optional NewValue As String = "[None]" _
)
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim prp As DAO.Property
    Const SubDatasheetPropertyName As String = "SubdatasheetName"
    
    Set db = CurrentDb
    For Each tdf In db.TableDefs
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If Len(tdf.Connect) = 0 And (Not tdf.Name Like "~*") Then 'Not attached, or temp.
                If TryGetProperty(tdf, SubDatasheetPropertyName, prp) Then
                    TrySetPropertyValue prp, NewValue
                Else
                    Set prp = tdf.CreateProperty(SubDatasheetPropertyName , dbText, NewValue)
                    tdf.Properties.Append prp
                End If
            End If
        End If
    Next
End Sub

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

बनाना TryCreateOrSetProperty प्रक्रिया

कोड अधिक पठनीय है लेकिन हमारे पास अभी भी वह Else है एक संपत्ति बनाने को रोकें। क्या हम अभी भी बेहतर कर सकते हैं? हां! आइए इस बारे में सोचें कि हमें यहां क्या हासिल करने की आवश्यकता है। हमारे पास ऐसी संपत्ति है जो मौजूद हो भी सकती है और नहीं भी। अगर ऐसा नहीं होता है, तो हम इसे बनाना चाहते हैं। यह पहले से मौजूद है या नहीं, हमें इसे एक निश्चित मूल्य पर सेट करने की आवश्यकता है। तो हमें जो चाहिए वह एक ऐसा फ़ंक्शन है जो या तो एक संपत्ति बनाएगा या मूल्य को अपडेट करेगा यदि यह पहले से मौजूद है। प्रॉपर्टी बनाने के लिए, हमें CreateProperty . पर कॉल करना होगा जो दुर्भाग्य से Properties . पर नहीं है बल्कि अलग-अलग डीएओ ऑब्जेक्ट्स। इस प्रकार, हमें Object . का उपयोग करके देर से बाइंड करना चाहिए डेटा प्रकार। हालाँकि, हम अभी भी त्रुटियों से बचने के लिए कुछ रनटाइम जाँच प्रदान कर सकते हैं। आइए एक TryCreateOrSetProperty बनाएं समारोह:

Public Function TryCreateOrSetProperty( _
    ByVal SourceDaoObject As Object, _
    ByVal PropertyName As String, _
    ByVal PropertyType As DAO.DataTypeEnum, _
    ByVal PropertyValue As Variant, _
    ByRef OutProperty As DAO.Property _
) As Boolean 
    Select Case True
        Case TypeOf SourceDaoObject Is DAO.TableDef, _
             TypeOf SourceDaoObject Is DAO.QueryDef, _
             TypeOf SourceDaoObject Is DAO.Field, _
             TypeOf SourceDaoObject Is DAO.Database
            If TryGetProperty(SourceDaoObject.Properties, PropertyName, OutProperty) Then
                TryCreateOrSetProperty = TrySetPropertyValue(OutProperty, PropertyValue)
            Else
                On Error Resume Next
                Set OutProperty = SourceDaoObject.CreateProperty(PropertyName, PropertyType, PropertyValue)
                SourceDaoObject.Properties.Append OutProperty
                If Err.Number Then
                    Set OutProperty = Nothing
                End If
                On Error GoTo 0
                
                TryCreateOrSetProperty = (OutProperty Is Nothing)
            End If
        Case Else
            Err.Raise 5, , "Invalid object provided to the SourceDaoObject parameter. It must be an DAO object that contains a CreateProperty member."
    End Select
End Function

ध्यान देने योग्य कुछ बातें:

• हम पहले के Try* . पर निर्माण करने में सक्षम थे फ़ंक्शन जिसे हमने परिभाषित किया है, जो फ़ंक्शन के शरीर के कोडिंग में कटौती करने में मदद करता है, जिससे यह ऐसी कोई संपत्ति न होने की स्थिति में निर्माण पर अधिक ध्यान केंद्रित करने की अनुमति देता है।
• अतिरिक्त रनटाइम जांच के कारण यह अनिवार्य रूप से अधिक क्रियात्मक है, लेकिन हम इसे सेट अप करने में सक्षम हैं ताकि त्रुटियां निष्पादन प्रवाह में परिवर्तन न करें और हम अभी भी बिना किसी कूद के ऊपर से नीचे तक पढ़ सकें।
• एक MsgBox फेंकने के बजाय कहीं से भी, हम Err.Raise . का उपयोग करते हैं और एक सार्थक त्रुटि लौटाएं। वास्तविक त्रुटि प्रबंधन को कॉलिंग कोड को सौंप दिया जाता है जो तब तय कर सकता है कि उपयोगकर्ता को संदेश बॉक्स दिखाना है या कुछ और करना है।
• हमारे द्वारा सावधानीपूर्वक संभालने और SourceDaoObject . प्रदान करने के कारण पैरामीटर मान्य है, सभी संभावित पथ गारंटी देते हैं कि मौजूदा संपत्ति के मूल्य को बनाने या सेट करने में किसी भी समस्या को संभाला जाएगा और हमें एक false मिलेगा नतीजा। यह कॉलिंग कोड को प्रभावित करता है जैसा कि हम जल्द ही देखेंगे।

कॉलिंग कोड का अंतिम संस्करण

आइए नए फ़ंक्शन का उपयोग करने के लिए कॉलिंग कोड को अपडेट करें:

Public Sub EditTableSubdatasheetProperty( _
    Optional NewValue As String = "[None]" _
)
    Dim db As DAO.Database
    Dim tdf As DAO.TableDef
    Dim prp As DAO.Property
    Const SubDatasheetPropertyName As String = "SubdatasheetName"
    
    Set db = CurrentDb
    For Each tdf In db.TableDefs
        If (tdf.Attributes And dbSystemObject) = 0 Then
            If Len(tdf.Connect) = 0 And (Not tdf.Name Like "~*") Then 'Not attached, or temp.
                TryCreateOrSetProperty tdf, SubDatasheetPropertyName, dbText, NewValue
            End If
        End If
    Next
End Sub

यह पठनीयता में काफी सुधार था। मूल संस्करण में, हमें कई If . की जांच करनी होगी ब्लॉक और कैसे त्रुटि प्रबंधन निष्पादन के प्रवाह को बदल देता है। हमें यह पता लगाना होगा कि सामग्री वास्तव में क्या कर रही थी ताकि यह निष्कर्ष निकाला जा सके कि हम एक संपत्ति प्राप्त करने या इसे बनाने की कोशिश कर रहे हैं यदि यह अस्तित्व में नहीं है और इसे एक निश्चित मूल्य पर सेट किया गया है। वर्तमान संस्करण के साथ, फ़ंक्शन के नाम पर यह सब कुछ है, TryCreateOrSetProperty . अब हम देख सकते हैं कि फ़ंक्शन से क्या करने की अपेक्षा की जाती है।

निष्कर्ष

आप शायद सोच रहे होंगे, “लेकिन हमने और भी बहुत से फ़ंक्शन और बहुत अधिक लाइनें जोड़ी हैं। क्या यह बहुत काम नहीं है?" यह सच है कि इस वर्तमान संस्करण में, हमने 3 और कार्यों को परिभाषित किया है। हालाँकि, आप प्रत्येक एकल फ़ंक्शन को अलगाव में पढ़ सकते हैं और फिर भी आसानी से समझ सकते हैं कि उसे क्या करना चाहिए। आपने यह भी देखा कि TryCreateOrSetProperty फ़ंक्शन 2 अन्य पर बना सकता है Try* कार्य। इसका मतलब है कि तर्क को एक साथ जोड़ने में हमारे पास अधिक लचीलापन है।

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

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

यह सब अमूर्त के बारे में है

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

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

इसलिए मुझे "कोशिश करें *" पैटर्न क्यों पसंद है। मुझे आशा है कि आप इसे अपनी परियोजनाओं के लिए भी उपयोगी पाएंगे।