क्या एक व्यापार नियम उल्लंघन एक अपवाद फेंकना चाहिए?

Question

क्या व्यवसाय नियम उल्लंघन एक अपवाद फेंकना चाहिए?

Answer 1

नहीं। यह प्रोग्राम में सामान्य सशर्त-हैंडलिंग तर्क का हिस्सा है (और अक्सर उपयोगकर्ता त्रुटि का एक छिपी हुई रूप)।

Answer 2

यह इस बात पर निर्भर करता है कि व्यापार नियम क्या है, आईएमओ। मैं "आम तौर पर नहीं" कहने का प्रयास करता हूं लेकिन मैं इसे केस-दर-मामले आधार पर देखता हूं। मुझे नहीं लगता कि कोई भी जवाब है, क्योंकि अलग-अलग व्यवसाय नियम इसे वारंट कर सकते हैं जबकि अन्य शायद नहीं।

Answer 3

जिस तरह से मैं अपना सत्यापन और ओआरएम के लिए LINQtoSQL का उपयोग करता हूं, हां। यदि कोई इकाई ऑनवालिडेट विधि के दौरान किसी व्यवसाय नियम पर सत्यापन विफल करती है, तो कॉलिंग कोड को सूचित करने का एकमात्र तरीका अपवाद को फेंकना है। इस मामले में, मैंने एक कस्टम DataValidationException फेंक दिया। इकाई के आंशिक वर्ग कार्यान्वयन में ऑनवालिडेट विधि हुक का उपयोग करना मेरे लिए अद्यतन/सम्मिलन पर सत्यापन लागू करना संभव बनाता है, इसलिए केवल वैध डेटा डेटाबेस में सहेजा जाता है।

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

Answer 4

क्या आपका मतलब है, उदाहरण के लिए, मान 0-99 की सीमा में होना चाहिए लेकिन किसी भी तरह 105 हो गया है?

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

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

Answer 5

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

Answer 6

यह वास्तव में इस बात पर निर्भर करता है कि यह क्या है और यह कहां है।

यदि यह उपयोगकर्ता से कुछ डेटा आ रहा है तो लेवैंड ने कहा कि यह सत्यापन की बात है। प्रमाणीकरण सफल और असफल दोनों को चालू कर सकता है, दोनों स्पष्ट आगे कार्रवाई परिदृश्यों के साथ अपेक्षित विकल्प हैं।

यदि यह विधि निष्पादन त्रुटियों की तरह कुछ है तो अपवाद फेंकना और अधिक नुकसान होने से पहले वहां पर रोकना बेहतर हो सकता है (जैसे डेटाबेस में असंगतताएं उत्पन्न करना)।

यह अक्सर परिप्रेक्ष्य और आपके आवेदन डिजाइन का विषय होता है।

Answer 7

आमतौर पर मैं एक विशिष्टता उद्देश्य यह है कि

bool IsVerfiedBy(T entity); 

लागू करता है तो तुम बिना किसी अपवाद के स्थिति की जांच कर सकते हैं में हालत डाल दिया।

यदि आपके कोड में कोई स्थान है जहां विनिर्देश पहले से सत्यापित किया जाना चाहिए, तो आप अपवाद फेंक सकते हैं क्योंकि यह आपके कार्य की एक पूर्व शर्त है।

उदाहरण के लिए यदि आपकी इकाई निरंतरता से पहले एक विशिष्ट स्थिति में होनी चाहिए, तो विनिर्देश सत्यापित नहीं होने पर अपवाद फेंक दें, लेकिन जारी होने से पहले विनिर्देश का उपयोग करें ताकि अपवाद न हो।

Answer 8

मैं सामान्य रूप से नहीं कहूंगा लेकिन मुझे नहीं लगता कि आप कभी नहीं कह सकते हैं।

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

Answer 9

अधिकतर उत्तर के लिए एक विकल्प के रूप में ... दृश्य

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

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

तो, संक्षेप ... यह निर्भर करता है ...

Answer 10

पहले, Jeffrey Richter द्वारा एप्लाइड माइक्रोसॉफ्ट .NET फ्रेमवर्क प्रोग्रामिंग (पेज 402) के 18 अध्याय से बोलियां की एक जोड़ी:

" एक और आम गलत धारणा यह है कि एक 'अपवाद' एक 'त्रुटि' की पहचान करता है। "

"एक अपवाद एक प्रोग्रामेटिक इंटरफ़ेस की अंतर्निहित मान्यताओं का उल्लंघन है।"

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

रिचटर के पहले उद्धरण (अपवाद! = त्रुटि) का एक अच्छा उदाहरण थ्रेडएबॉर्ट अपवाद है। यदि आप Response.Redirect (url) (ASP.NET में) कहते हैं, तो रीडायरेक्ट सफल होने के बावजूद थ्रेडएबॉर्ट अपवाद फेंक दिया जाता है। क्यूं कर? एएसपी.नेट पेज निष्पादन की अंतर्निहित धारणा यह है कि एक पृष्ठ पूरी तरह से निष्पादित होगा। Response.Redirect (url) इस धारणा का उल्लंघन करता है, इसलिए अपवाद।

Answer 11

व्यवसाय नियमों को अपवाद नहीं फेंकना चाहिए, जब तक कि उन्हें कुछ एपीआई के मानकों को सत्यापित करने के लिए उपयोग नहीं किया जाता है (यानी: सत्यापन अनुरोध वैधता) या यूनिट परीक्षणों में (यानी using business rules to simplify .NET unit tests)।

आम तौर पर व्यवसाय नियम आउटपुट त्रुटि और चेतावनी संदेशों को सत्यापन दायरे में चेतावनी देते हैं।

Answer 12

नहीं व्यवसाय नियम का उल्लंघन करना एक व्यवसाय मुद्दा है जहां एक अपवाद तकनीकी है। एक व्यापार नियम का उल्लंघन करना कुछ ऐसा है जो सिस्टम को सामान्य ऑपरेशन के रूप में माना जाना चाहिए और जिसके लिए इसे प्रोग्राम किए गए प्रतिक्रिया होनी चाहिए, अपवाद नहीं।

Answer 13

व्यवसाय नियम अपवाद फेंक सकते हैं लेकिन उन्हें नहीं करना चाहिए।

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

Answer 14

अध्याय Distinguish Business Exceptions from Technical में wiki for the book97 हालात हर परियोजना प्रबंधक में अच्छा मार्गदर्शन पता होना चाहिए, विशेष रूप से नहीं है।

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