यहाँ कैसे हम इस समस्या के दृष्टिकोण है। अंतर्निहित परतों द्वारा किए गए सभी कार्यों में अपना स्वयं का प्रयास होता है, जो कस्टम अपवाद को लॉग, लपेट और फेंक देता है। यूआई फिर इस पर भरोसा कर सकता है और दोस्ताना त्रुटि संदेशों के साथ हैंडल अपवादों की तलाश कर सकता है।
codebehind:
protected void btnSubmit_Click(object sender, EventArgs e)
{
//do something when a button is clicked...
try
{
MyBL.TakeAction()
}
catch(MyApplicationCustomException ex)
{
//display something to the user, etc.
ltlErrorPane.Text = ex.Message;
//or redirect if desired
if(ex.ErrorType == MyCustomErrorsType.Transactional)
{
Response.Redirect("~/Errors/Transaction.aspx");
}
}
}
बीएल:
व्यापार परत में, किसी भी आपरेशन जो प्रयोग विफल हो सकता है एक कोशिश पकड़ है, जो लॉग करता है और करने के लिए इसे फेंकने से पहले इस मुद्दे को लपेटता यूआई।
public class MyBL
{
public static void TakeAction()
{
try
{
//do something
}
catch(SpecificDotNetException ex)
{
//log, wrap and throw
MyExceptionManagement.LogException(ex)
throw new MyApplicationCustomException(ex, "Some friendly error message", MyCustomErrorsType.Transactional);
}
finally
{
//clean up...
}
}
}
अपवाद हैंडलर:
वास्तविक अपवाद संचालक लॉग इन करने के कई तरीके, ईवेंट लॉग, फ़ाइल लॉग और अंत में ईमेल अगर सब कुछ विफल शामिल है। अगर लॉगर अपेक्षित कार्यों में से कोई भी कार्य नहीं कर सकता है तो हम सामान्य वापसी झूठी चुनते हैं। आईएमओ हालांकि यह एक व्यक्तिगत पसंद है। हम समझते हैं कि उत्तराधिकार में विफल होने वाली 3 विधियों की संभावना (इवेंट लॉग विफल रहता है, फ़ाइल लॉग आज़माएं, विफल रहता है, ईमेल आज़माएं, विफल रहता है) बहुत ही असंभव है। इस मामले में हमने ऐप को जारी रखने की अनुमति देना चुना। आपका दूसरा विकल्प ऐप को पूरी तरह विफल होने की अनुमति देना होगा।
public static class MyExceptionManagement
{
public static bool LogException(Exception ex)
{
try
{
//try logging to a log source by priority,
//if it fails with all sources, return false as a last resort
//we choose not to let logging issues interfere with user experience
//if logging worked
return true;
}
catch(Exception ex)
{
//in most cases, using try-catch as a true-false is bad practice
//but when logging an exception causes an exception itself, we do
//use this as a well-considered choice.
return false;
}
}
}
अन्त में, एक असफल-सुरक्षित के रूप में, हम Application_Error वैश्विक ईवेंट हैंडलर (Global.asax में) लागू करते हैं। यह उन मामलों के लिए एक अंतिम उपाय है जहां हमने कुछ सही तरीके से प्रयास नहीं किया था। हम आम तौर पर एक दोस्ताना त्रुटि पृष्ठ पर लॉग इन और रीडायरेक्ट करते हैं। यदि उपर्युक्त कस्टम त्रुटि प्रबंधन सफलतापूर्वक किया जाता है, तो बहुत कम त्रुटियां इसे वैश्विक हैंडलर में लाएंगी।
उम्मीद है कि इससे थोड़ा सा मदद मिल सकती है। यह एक संभावित समाधान है। इसने कुछ बड़े अनुप्रयोगों पर कई वर्षों तक हमारे लिए बहुत अच्छा काम किया है ..
उम्मीद है कि यह सिर्फ छद्म कोड है, लेकिन आपको शायद एक सामान्य अपवाद को पकड़ना नहीं चाहिए। –
कैच-ऑल के रूप में एक सामान्य अपवाद को पकड़ना ठीक है, जब तक कि आपने पहले विशिष्ट अपवादों को पकड़ने की कोशिश की है (क्योंकि आप प्रति प्रयास कई कैच कर सकते हैं) ... ऊपर अकेले हां अधिक विशिष्ट होना चाहिए ... –
इसके लायक होने के लिए, मैं पहले त्रुटि लॉग करूंगा। यदि Transaction.voidorder में कोई अपवाद है, तो आपके पास –