संग्रहित प्रक्रिया एपीआई के लिए सर्वोत्तम अभ्यास?

Question

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

3-पक्ष क्लाइंट को केवल कुछ sprocs के लिए, सीधे मेज पर नहीं पहुंच पाएंगे। स्पॉक्स द्वारा छुपाई गई तालिका अच्छी तरह से बाधित है, लेकिन जब तक स्पॉक्स गलत तरीके से बुलाए जाते हैं, तब तक हम विस्तृत त्रुटि जानकारी प्रदान करते हुए उपयोगकर्ता के अनुकूल के रूप में बनना चाहते हैं।

Answer 1

सूचनात्मक त्रुटि संदेश प्रदान करना मुश्किल नहीं है जो मनुष्य समझ सकता है। एक वर्णनात्मक पाठ के साथ बस RAISERROR। स्थानीय ग्रंथों को बढ़ाने के लिए थोड़ा और मुश्किल है, जो sp_addmessage और परिवार के उचित उपयोग का तात्पर्य है। असली हार्ड समस्या उस त्रुटि को बढ़ा रही है जिसमें एक प्रोग्राम प्रतिक्रिया दे सकता है। यह ठीक से उन्हें अपने एपीआई में उपयोग करने में त्रुटि कोड (और गंभीरता और राज्य), और गंभीर कोड अनुशासन दस्तावेज का मतलब है।

और उचित लेन-देन नेस्टिंग मत भूलना। मेरे पास इस ब्लॉग पर एक नमूना है कि टी-एसक्यूएल अपवादों के साथ संयोजन में लेनदेन को सही ढंग से कैसे संभालना है: Exception handling and nested transactions।

दुर्भाग्य से पूरे ग्राहक/T-SQL ढेर की तुलना में एक की तुलना में अपवाद पर कला के राज्य में कुछ समस्याएं हैं। सबसे उल्लेखनीय यह है कि यदि आप टी-एसक्यूएल अपवाद पकड़ते हैं, तो आप इसे फिर से नहीं हटा सकते हैं, इसलिए आपका ग्राहक सामान्य सिस्टम त्रुटि संख्या की अपेक्षा नहीं कर सकता है। SQL सर्वर देखें: Rethrow exception with the original exception number। यह 50000 से अधिक रेंज है, जो 'transalated' त्रुटि कोड की संख्या बढ़ जाती है, और अपवाद जानकारी के रूप में त्रुटि संदेश स्ट्रिंग का उपयोग के रूप में बहुत बोझिल है पर अपने खुद के त्रुटि संख्या का उपयोग करने से उचित त्रुटि जानकारी संवाद करने के लिए, अन्य छोटे साधन के साथ छोड़ देता है ।

Answer 2

• उपयोग ट्राई/कैच ब्लॉक
• फेंक सार्थक संदेश (मैं इस तरह के रूप में एक उपसर्ग का उपयोग "जानकारी:" डेटाबेस त्रुटियों से मेरी त्रुटियों भेद करने के लिए)

उदाहरण:

SET NOCOUNT, XACT_ABORT ON 
... 
BEGIN TRY 
    IF @parameter1 IS NULL 
     RAISERROR ('INFO: "parameter1" should not be blank', 16, 1) 

    IF @parameter2 < 0 
     RAISERROR ('INFO: "parameter2" must be greate then zero', 16, 1) 

    ... 

END TRY 
BEGIN CATCH 
    DECLARE @MyError nvarchar(2048) 
    SELECT @MyError = ERROR_MESSAGE() -- + other stuff, like stored proc name perhaps 
    RAISERROR (@MyError, 16, 1) 
    ... 
END CATCH