2011-08-25 17 views
6

मुझे पता है कि इस पर अन्य विषयों पर भी चर्चा की गई थी, जो मैं पूछ रहा हूं वह वास्तव में इस प्रश्न का शीर्षक है।डेल्फी - अंततः ब्लॉक को सही ढंग से निष्पादित करने के लिए संकलक द्वारा गारंटी दी जाती है?

क्या ऐसा कोई मामला है जब आखिर में आखिरकार निष्पादित नहीं होगा?

try 
    //some error here 
finally 
    //code that MUST be executed 
end; 

मैं कैसे try..except/अंत में ब्लॉक इस्तेमाल किया जाना चाहिए के बारे में बात नहीं कर रहा हूँ, मैं सिर्फ अगर यह भी हो सकता है पूछ रहा हूँ।

LE: आवेदन। अपने कंप्यूटर को अनधिकृत/अनप्लग करें विशेष मामले हैं।

+2

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

+1

मैं इस प्रश्न को देख रहा था http://stackoverflow.com/questions/3484353/is-there-such-case-when-in-try-finally-block-the-finally-wont-be-executed - ऐसा लगता है कि जावा डेवलपर्स दुनिया/आदि के वर्महोल्स/अंत के बारे में नहीं सोचते हैं। मुझे यह स्वीकार करना होगा कि डेल्फी डेवलपर्स के पास Win12 में – RBA

+0

की भावना नहीं है। लेकिन यह संकलक द्वारा गारंटीकृत है? –

उत्तर

22

try..finally गारंटी देता है कि अंत में ब्लॉक में कोड संरक्षित ब्लॉक में होने वाले किसी भी अपवाद के बावजूद निष्पादित करेगा। अंततः ब्लॉक निष्पादित करने से पहले प्रक्रिया को मारने पर यह लागू नहीं होता है, उदा। TerminateProcess द्वारा या बिजली बंद कर रहा है। संरक्षित ब्लॉक में एक अंतहीन पाश अंततः ब्लॉक को निष्पादित करने से रोक सकता है।

+11

+1। लूप के लिए –

+0

+1 भी। –

+15

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

4

यदि बिजली गुम हो जाती है (उदाहरण के लिए, यदि आप कंप्यूटर को अनप्लग करते हैं और इसमें कोई बैटरी नहीं है और यूपीएस से कनेक्ट नहीं है), तो यह बहुत संभव है कि finally ब्लॉक नहीं चलाया जाएगा। एक प्रमुख ओएस या ड्राइवर खराब होने (जैसे कि बीएसओडी) भी इसका कारण बन सकता है। हालांकि, try..finally निर्माण के साथ पूरा विचार यह है कि ब्लॉक को तब भी चलाया जाना चाहिए जब try ब्लॉक के अंदर कोई अपवाद (किसी भी प्रकार का) उठाया गया हो। finally ब्लॉक कथन try ब्लॉक के अंदर भी होगा यदि ब्लॉक भी चलाएगा।

+0

+1 के बाद हास्य – RBA

+3

@ आरबीए: क्या, उत्साहजनक? कंपाइलर गारंटी नहीं दे सकता कि मेजबान कंप्यूटर (हार्डवेयर/ओएस/ड्राइवर) ठीक तरह से काम करेगा ... हालांकि, मुझे लगता है कि आप 'गारंटीकृत' हैं कि 'आखिरकार' ब्लॉक चलाया जाता है यदि सामान्य 'ESomeException को बढ़ाएं। बनाएं (...) '' try' के अंदर हिट किया गया है (और कुछ भी नहीं होता है, जैसे कंप्यूटर को ब्लैक होल या कुछ में चूसा जाता है)। –

+2

+1। मैं 'ब्लैक होल' रेफरी के लिए एक और +1 दूंगा। अगर मैं कर सकता। :) –

3

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

1

एक बार प्रयास/अंत में प्रवेश करने के बाद, आखिरकार निष्पादन प्रयास/अंत में निष्पादन से पहले निष्पादित हो जाएगा।

+0

आखिरकार ब्लॉक _start_ निष्पादन करेगा। बस उम्मीद है कि ब्लॉक के अंदर कुछ भी नहीं फेंकता है। –

+0

@henk जो आखिरकार ब्लॉक में फेंकता कोड लिखता है? –

+0

क्या आप उन्हें एक बियर खरीदना चाहेंगे? –

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