2015-09-12 7 views
13

यदि कोई .NET प्रोग्राम समाप्त होने से पहले निकास कोड को स्पष्ट रूप से सेट करने में विफल रहता है (Environment.Exit()/Appliation.Current.Shutdown()/... पर कॉल करके), उस प्रक्रिया के लिए निकास कोड क्या है?कौन से निकास कोड एक .NET प्रोग्राम कर सकते हैं, जब Environment.Exit() का उपयोग नहीं किया जाता है?

क्या सामान्य समाप्ति हमेशा निकास कोड शून्य में परिणाम देती है, और अन्य संभावित मामले क्या हैं?

हंस Passant से संबंधित सवाल Getting ExitCode From Exception Handler को this answer के अनुसार: "अगर एक कार्यक्रम एक अपवाद पर मर जाता है तो इसकी बाहर निकलें कोड सामान्य रूप से अंतर्निहित अपवाद त्रुटि कोड रूप में ही है"।

तो एक अनजान अपवाद निकास कोड को व्यवस्थित कर सकता है। क्या यह हमेशा मामला है, और क्या अंतर्निहित अपवाद त्रुटि कोड हमेशा शून्य से अलग है, और एक विशिष्ट सीमा में है?

क्या ऐसी अन्य परिस्थितियां हैं जहां नेट फ्रेमवर्क या विंडोज स्वचालित रूप से एक अन्य निकास कोड सेट कर सकते हैं, जैसे कि कुछ अपवाद अपरिचित क्रैश (क्या यह संभव है?), या एक मजबूर कार्य हत्या?

इसे एक और तरीका रखने के लिए, क्या मैं निकास कोड द्वारा निर्धारित कर सकता हूं कि प्रोग्राम किसी असामान्य फैशन में समाप्त हो गया है या नहीं?
या यदि कुछ असामान्य मामलों में शून्य का निकास कोड भी हो सकता है, तो क्या मैं प्रोग्राम के लिए सभी सामान्य समाप्ति पथों में Environment.Exit(somevalue) शामिल कर सकता हूं, और सुनिश्चित करें कि यह निकास कोड किसी दुर्घटना के मामले में कभी नहीं हो सकता है?


प्रेरणा:
not all exeptions are catchable गंभीर समाधान के बिना के बाद से, और के बाद से अचानक कार्यक्रम ध्यान में न आया excpetions के अलावा अन्य समाप्ति, बनाने के लिए अन्य कारणों भी हो सकते हैं सुनिश्चित करें कि सभी कोड पथ फोन Environment.Exit() alwas संभव नहीं है। यही कारण है कि मुझे यह निर्धारित करने में दिलचस्पी है कि निकास कोड का उपयोग विश्वसनीय रूप से यह बताने के लिए किया जा सकता है कि कोई प्रोग्राम सामान्य रूप से बाहर निकला है या नहीं।

+0

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

+0

टैंगेंटल सुझाव: मिनीडंप सक्षम बनाने के विकल्प के साथ, विंडोज त्रुटि रिपोर्टिंग सक्षम करें। इस तरह से आपके पास न केवल निकास कोड होता है, बल्कि अपवाद रिकॉर्ड और आंशिक ढेर भी जिन्हें आप डीबगर से गुजर सकते हैं। (एसओएस डीबगर का उपयोग कर WinDBG की तरह।) यहां तक ​​कि मिनीडंप के बिना भी WER त्रुटि संदेश के बारे में कुछ जानकारी प्राप्त करता है। एक आंतरिक अनुप्रयोग के लिए, आप क्रैश रिपोर्ट स्वचालित रूप से सबमिट होने के लिए भी एक सर्वर स्थापित कर सकते हैं। यह [पेज] (https://technet.microsoft.com/en-us/library/cc709644.aspx) TechNet पर एक अच्छा अवलोकन है। – theB

+0

निकास कोड बहुत बेकार IMHO है। यहां और अधिक: http://stackoverflow.com/questions/4344923/process-exit-code-when-process-is-killed-forcibly –

उत्तर

5

तो इसकी बाहर निकलें कोड सामान्य रूप से अंतर्निहित अपवाद त्रुटि कोड

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

वहां बहुत अधिक सामान है जो इसमें शामिल होना चाहता है और यह हमेशा सर्वोत्तम गुणवत्ता का नहीं है। सूची के शीर्ष पर निश्चित रूप से एंटी-मैलवेयर है, वहां बहुत सारे cr * pware हैं और आप कभी नहीं जानते कि आप क्या चलते हैं। हाल ही में अवास्ट आपदा इस बारे में चिंतित होने के कई कारण बताती है। लगभग यह नहीं कहां समाप्त होता है, WER को प्रतिस्थापित करने वाली उपयोगिताएं काफी आम हैं।

और आप एक योकेल के खिलाफ पूरी तरह से असुरक्षित हैं जो सोचता है कि TerminateProcess() फ़ाइल लॉकिंग समस्या को हल करने का एक अच्छा तरीका है। या कोई पावर कॉर्ड पर जा रहा है और मशीन को अनप्लग कर रहा है।

पर थोड़ा सा फ़ोकस करें क्यों आप निकास कोड जानना चाहते हैं।ऐसा कुछ होना चाहिए जो आप आगे करते हैं जो निष्पादन जारी रखने के लिए कार्यक्रम के परिणाम का उपयोग करता है। परिणाम की पुष्टि करें।

2

क्या आप अपनी प्रक्रिया को निष्पादित कर रहे हैं? यही है, क्या आप अनुमानित परिस्थितियों में अपने निकास कोड को नियंत्रित कर सकते हैं? यदि ऐसा है, तो आप किसी भी अपवाद को फेंक सकते हैं और फिर अपना अनुमानित गैर-शून्य अपवाद कोड (एक विशिष्ट मूल्य या अपनी खुद की रेंज) वापस कर सकते हैं। मैं एक नकारात्मक संख्या का उपयोग करूंगा क्योंकि सिस्टम त्रुटि कोड सकारात्मक हैं। इस तरह आप तीन संभावनाएं मिल गया है:

  1. शून्य - सफलता
  2. नकारात्मक - प्रक्रिया एक अपवाद है कि आप
  3. सकारात्मक को पकड़ने के लिए सक्षम थे फेंक दिया - प्रक्रिया एक अपवाद है कि आप पकड़ नहीं सकता है फेंक दिया। वह असामान्य होगा।

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

मुझे नहीं पता कि # 3 भी संभव है, लेकिन यदि आप अज्ञात के लिए खाते की कोशिश कर रहे हैं तो शायद यह संभवतः आप कर सकते हैं।

यहाँ एक उदाहरण है:

internal class Program 
{ 
    private static void Main(string[] args) 
    { 
     var exitCode = 0; 
     try 
     { 
      //do something 
     } 
     catch (SystemException systemEx) 
     { 
      //log 
      exitCode = -systemEx.HResult; 
     } 
     catch (Exception ex) 
     { 
      //log 
      Environment.ExitCode = int.MinValue; 

     } 
     Environment.ExitCode = exitCode; 
    } 
} 

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

संबंधित मुद्दे