विचार

Question

कोड है कि इस तरह दिखता है पर आपके क्या विचार हैं:

public void doSomething() 
{ 
    try 
    { 
     // actual code goes here 
    } 
    catch (Exception ex) 
    { 
     throw; 
    } 
} 

समस्या मैं देख रहा हूँ वास्तविक त्रुटि से संभाला नहीं है, बस एक अलग जगह में अपवाद फेंक। मुझे डीबग करना अधिक कठिन लगता है क्योंकि मुझे एक लाइन नंबर नहीं मिलता है जहां वास्तविक समस्या है।

तो मेरा सवाल यह है कि यह अच्छा क्यों होगा?

---- संपादित ----

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

Answer 1

आप जिस गुणवत्ता को देख रहे हैं उसके आधार पर यह अपवाद को किसी अलग स्थान पर नहीं फेंक रहा है। एक लक्ष्य के बिना "फेंक" अपवाद को पुनर्जीवित करने से बहुत अलग है अपवाद को पुनर्स्थापित करता है। मुख्य रूप से एक रेथ्रो स्टैक ट्रेस रीसेट नहीं करता है।

इस विशेष नमूने में, पकड़ व्यर्थ है क्योंकि यह कुछ भी नहीं करता है। अपवाद खुशी से पुनर्स्थापित किया गया है और यह लगभग है जैसे प्रयास/पकड़ मौजूद नहीं था।

Answer 2

मैंने ऐसे उदाहरण देखे हैं जहां सामान्य अपवाद इस तरह पकड़े जाते हैं और फिर कस्टम अपवाद ऑब्जेक्ट में फिर से पैक किए जाते हैं।

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

Answer 3

मुझे लगता है कि निर्माण को उन अपवादों को संभालने के लिए उपयोग किया जाना चाहिए जिन्हें आप जानते हैं कि आप अपने कोड के अंदर फेंक देंगे; यदि अन्य अपवाद उठाया गया है, तो बस फिर से उखाड़ फेंक दें।

ध्यान दें कि फेंक; से पहले अलग है;

फेंकने पूर्व अपवाद के बारे में मूल्यवान जानकारी खोने, फेंकने के नए बिंदु पर ढेर को छीन देगा।

public void doSomething() 
{ 
    try 
    { 
     // actual code goes here 
    } 
    catch (EspecificException ex) 
    { 
     HandleException(ex); 
    } 
    catch (Exception ex) 
    { 
     throw; 
    } 
} 

Answer 4

शुरुआत के लिए

खैर मैं बस

catch 
{ 
    throw; 
} 

करना चाहते हैं लेकिन मूल रूप से यदि आप अपवादों में से कई प्रकार के फँसाने थे आप कुछ स्थानीय रूप से संभालने के लिए चाहते हो सकता है और दूसरों के ढेर का बैक अप।

उदा।

catch(SQLException sex) //haha 
{ 
    DoStuff(sex); 
} 
catch 
{ 
    throw; 
} 

Answer 5

ऐसा ही कुछ कर काफी व्यर्थ है, और सामान्य रूप में मैं व्यर्थ काम करने के सड़क के नीचे जाने के लिए नहीं की कोशिश;)

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

Answer 6

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

Answer 7

यह नहीं होगा, आदर्श कैच ब्लॉक कुछ हैंडलिंग करना होगा, और फिर rethrow, जैसे,

try 
{ 
    //do something 
} 
catch (Exception ex) 
{ 
    DoSomething(ex); //handle the exception 
    throw; 
} 

बेशक फिर से फेंकना उपयोगी होगा यदि आप कोड के ऊपरी स्तर में कुछ और हैंडलिंग करना चाहते हैं।

Answer 8

कभी-कभी यह उचित होता है - जब आप कॉल स्टैक में अपवाद को ऊपर उठाने जा रहे हैं। हालांकि, आपको समझने के लिए इसे फिर से फेंकने के अलावा उस पकड़ ब्लॉक में कुछ करने की आवश्यकता होगी, उदा। त्रुटि लॉग करें:

public void doSomething() 
{ 
    try 
    { 
     // actual code goes here 
    } 
    catch (Exception ex) 
    { 
     LogException (ex); // Log error... 
     throw; 
    } 
} 

Answer 9

मुझे नहीं लगता कि केवल त्रुटि को पुनर्स्थापित करना उपयोगी होगा। जब तक कि आप वास्तव में पहली जगह में त्रुटि की परवाह नहीं करते हैं।

मुझे लगता है कि वास्तव में पकड़ में कुछ करना बेहतर होगा।

आप MSDN Exception Handling Guide देख सकते हैं।

Answer 10

आम तौर पर अपवाद हैंडलिंग ब्लॉक जो कुछ भी नहीं करते हैं, बिल्कुल आसान नहीं है, सरल कारण यह है कि यह नेट कोड वर्चुअल मशीन को आपके कोड को अनुकूलित करने पर आपके तरीकों को रेखांकित करने से रोकता है।

क्यों देखते हैं पर एक पूर्ण लेख के लिए "Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks" Scott Hanselman द्वारा