'অবিরত' বিবৃতিটি 'অবশেষে' ব্লকের ভিতরে থাকতে পারে না কেন?

Question

আমার কোন সমস্যা নেই; আমি উৎসুক. নিম্নলিখিত পরিস্থিতিতে কল্পনা করুন:

foreach (var foo in list)
{
    try
    {
         //Some code
    }
    catch (Exception)
    {
        //Some more code
    }
    finally
    {
        continue;
    }
}

এটি সংকলন করবে না, কারণ এটি সংকলক ত্রুটি CS0157 উত্থাপন করে :

নিয়ন্ত্রণটি শেষ অবধি শৃঙ্খলা ছেড়ে দেবে না

কেন?

Comments

So. উৎসুক. এটি যদি আপনার কাছে সম্পূর্ণরূপে বোঝায় তবে এটি কেন সংকলন করবে না, আপনি ইতিমধ্যে যে বোধগম্য তা কি কেউ ব্যাখ্যা করতে চান? =)

— জে। স্টিন

কেন আপনি একটি প্রয়োজন হবে continue;মধ্যে finallyঅবরোধ করবেন? এটি ব্লকের continue;পরে যেমন হয় না try -- catch?

— বনসি

@ জে.স্টিন না, আমি জানি যে এটি finally/continueসি # সংকলকের একটি সীমাবদ্ধতা :-) আমি এই সীমাবদ্ধতার কারণ সম্পর্কেও আগ্রহী।

— xanatos

@ এক্সানাটোস - প্রযুক্তিগতভাবে বলতে গেলে এটি অন্তর্নিহিত সিআইএল-এর একটি সীমাবদ্ধতা। থেকে ভাষা বৈশিষ্ট : "কন্ট্রোল স্থানান্তর ব্যতিক্রম হ্যান্ডলিং প্রক্রিয়া মাধ্যমে ছাড়া একটি ধরা হ্যান্ডলার বা পরিশেষে দফা প্রবেশ করতে অনুমতি না হয়।" এবং "একটি সুরক্ষিত অঞ্চল থেকে নিয়ন্ত্রণের স্থানান্তর কেবল ব্যতিক্রম নির্দেশের (অনুমতি, প্রান্তে ফিল্টার, এন্ড.ক্যাচ বা শেষ.ফিনালি) এর মাধ্যমে অনুমোদিত is" brশাখা নির্দেশাবলীর পরিবার এই কাজ করা সম্ভব করতে পারবে না।

— সাইন করা হয়নি

@ স্বাক্ষরিত: এটিও একটি দুর্দান্ত সীমাবদ্ধতা, এটি উদ্ভট হয়ে উঠবে :)

— ব্যবহারকারীর 11116

Answer 1

finallyএকটি ব্যতিক্রম ছুঁড়েছে কিনা তা ব্লকগুলি চালায়। যদি একটি ব্যতিক্রম নিক্ষেপ করা হয়, হেক কি করবে continue? আপনি লুপটির সম্পাদন চালিয়ে যেতে পারবেন না, কারণ অপ্রকাশিত ব্যতিক্রম অন্য ফাংশনে নিয়ন্ত্রণ স্থানান্তর করবে।

এমনকি যদি কোনও ব্যতিক্রম ছুঁড়ে না দেওয়া হয়, finallyতখন চালানো হবে যখন চেষ্টা / ক্যাচ ব্লক রানের অভ্যন্তরে অন্যান্য নিয়ন্ত্রণ স্থানান্তর বিবৃতিগুলি returnউদাহরণস্বরূপ, যা একই সমস্যা নিয়ে আসে।

সংক্ষেপে, এর শব্দার্থক শব্দগুলির সাথে finallyএটি কোনও finallyব্লকের ভিতরে থেকে এর বাইরের দিকে নিয়ন্ত্রণ স্থানান্তর করার অনুমতি দেওয়ার কোনও মানে হয় না।

কিছু বিকল্প শব্দার্থবিজ্ঞানের সাথে এটি সমর্থন করা সহায়তার চেয়ে আরও বিভ্রান্তিকর হতে পারে, যেহেতু এমন সাধারণ কাজকর্ম রয়েছে যা উদ্দেশ্যমূলক আচরণের উপায়কে আরও পরিষ্কার করে দেয়। সুতরাং আপনি একটি ত্রুটি পান এবং আপনার সমস্যা সম্পর্কে সঠিকভাবে চিন্তা করতে বাধ্য হন। এটি সাধারণ "আপনাকে সাফল্যের গর্তে ফেলে দেবে" ধারণা যা সি # তে চলে।

আপনি যদি ব্যতিক্রম উপেক্ষা করতে চান (তবে প্রায়শই খারাপ ধারণা নয়) এবং লুপটি চালিয়ে যেতে চান, সমস্ত ব্লক ধরুন:

foreach ( var in list )
{
    try{
        //some code
    }catch{
        continue;
    }
}

যদি আপনি continueকেবল তখনই চান যখন কোনও অপ্রকাশিত ব্যতিক্রম না ছড়িয়ে দেওয়া হয়, কেবল continueচেষ্টা-ব্লকের বাইরে রাখুন।

Comments

আমি এটিকে উত্তর হিসাবে গ্রহণ করব, কারণ মাইক্রোসফ্ট সম্ভবত যে কারণে অবশেষে একটি ধারাবাহিকতা গ্রহণ না করার সিদ্ধান্ত নিয়েছে সে কারণগুলি আপনি বুঝতে পেরেছেন। সম্ভবত ছবিগুলি আমাকেও বিশ্বাস করেছে :)

— lpaloub

আপনি কি "সাফল্যের গর্তে ফেলে দেবেন" ধারণাটি বিশদভাবে বর্ণনা করতে পারেন? আমি এটি পেলাম না :-D

— এন্ট

@ এ্যান্ট

— জোশ

ছবিটি জন স্কিটি, বিটিডব্লিউ তৈরি করেছিলেন। আমি এখান থেকে পেয়েছি: এমএসএমভিপিএস

— আর মার্টিনহো ফার্নান্দেস

অবশ্যই এটি যদি ব্লকের অভ্যন্তরে সংজ্ঞায়িত স্থানীয় লুপটি অবিরত করে থাকে তবে continueএকটি finallyব্লকের একটি ঠিক আছে finally। প্রশ্নে, তবে এটি "বাইরের" লুপটি চালিয়ে যাওয়ার চেষ্টা করে। একই বিবৃতি আপনি একটি ভিতরে থাকতে পারে না যে finallyব্লক হয় return, break(যখন ব্লক থেকে বের ভঙ্গ) এবং goto(যখন বাইরে একটি লেবেল যাচ্ছে finallyব্লক)। সম্পর্কিত জাভা আলোচনার জন্য, জাভাতে শেষ অবধি ব্লক থেকে ফিরে আসা দেখুন ।

— জেপ্প স্টিগ নীলসেন

Answer 2

এখানে একটি নির্ভরযোগ্য উত্স:

একটি অবিরত বিবৃতিটি শেষ অবধি (বিভাগ 8.10) প্রস্থান করতে পারে না। যখন অবিরত বিবৃতিটি একটি শেষ অবরুদ্ধ ব্লকের মধ্যে ঘটে তখন অব্যাহত বিবৃতিটির লক্ষ্য একই অবশেষে ব্লকের মধ্যে থাকতে হবে; অন্যথায়, একটি সংকলন-সময় ত্রুটি ঘটে।

এটি এমএসডিএন থেকে নেওয়া হয়েছে, ৮.৯.২ চালিয়ে যাওয়ার বিবৃতি ।

ডকুমেন্টেশন বলে যে:

নিয়ন্ত্রণ যখন একটি চেষ্টা করার স্টেটমেন্ট দেয় তখন সবশেষে ব্লকের স্টেটমেন্টগুলি সর্বদা কার্যকর করা হয়। একটি নিয়ন্ত্রণ কার্যকর করা, বিরতি কার্যকর করা, চালিয়ে যাওয়া, বা রিটার্ন বিবৃতি প্রদানের চেষ্টা হিসাবে বা ট্রাই স্টেটমেন্টের বাইরে কোনও ব্যতিক্রম প্রচারের ফলস্বরূপ নিয়ন্ত্রণ ট্রান্সফারটি সাধারণ সম্পাদনের ফলাফল হিসাবে ঘটে কিনা তা সত্য is যদি শেষ অবধি কার্যকর করার সময় কোনও ব্যতিক্রম ছুঁড়ে দেওয়া হয়, তবে ব্যতিক্রমটি পরবর্তী সংলগ্ন চেষ্টা বিবৃতিতে প্রচার করা হয়। অন্য কোনও ব্যতিক্রম প্রচারের প্রক্রিয়াতে থাকলে, সেই ব্যতিক্রমটি হারিয়ে যায়। একটি ব্যতিক্রম প্রচারের প্রক্রিয়াটি নিক্ষিপ্ত বিবৃতি (বিভাগ 8.9.5) এর বর্ণনায় আরও আলোচনা করা হয়।

এটি এখানে থেকে 8.10 চেষ্টা বিবৃতি ।

Answer 3

আপনি এটি বোধগম্য মনে করতে পারেন, কিন্তু আসলে এটি বোধগম্য নয় ।

foreach (var v in List)
{
    try
    {
        //Some code
    }
    catch (Exception)
    {
        //Some more code
        break; or return;
    }
    finally
    {
        continue;
    }
}

কোনও ব্যতিক্রম নিক্ষেপ করা হলে আপনি বিরতি বা চালিয়ে যাওয়ার কী চান ? সি # সংকলক দলটি ধরে নিয়ে breakবা এর দ্বারা সিদ্ধান্ত নিতে চায় না continue। পরিবর্তে, তারা অভিযোগ করার সিদ্ধান্ত নিয়েছে যে বিকাশকারী পরিস্থিতি এখান থেকে নিয়ন্ত্রণ স্থানান্তর করতে দ্বিধাবিভক্ত হবে finally block।

সুতরাং বিকাশকারীর কাজ অন্য কিছু অনুমানের পরিবর্তে তিনি কী করতে চান তা স্পষ্ট করে জানিয়ে দেওয়া state

আমি আশা করি আপনি বুঝতে পারেন কেন এটি সংকলন করে না!

Comments

সম্পর্কিত নোটে, "ধরা" না থাকলেও, একটি finallyবিবৃতি অনুসরণের মৃত্যুদন্ডের পথটি catchব্যতিক্রম হয়ে বেরিয়ে এসেছিল কিনা তা দ্বারা প্রভাবিত হবে এবং এটি কীভাবে এটির সাথে ইন্টারঅ্যাক্ট করতে হবে তা বলার কোনও ব্যবস্থা নেই continue। যদিও আপনার উদাহরণটি আমি পছন্দ করি কারণ এটি আরও বড় সমস্যা দেখায়।

— সুপারক্যাট

@ সুপের্যাট আপনার সাথে একমত, আমার উত্তরটি সংকলকটির জন্য অস্পষ্ট পরিস্থিতির একটি উদাহরণ দেখায় এখনও এই পদ্ধতির সাথে অনেকগুলি সমস্যা রয়েছে।

— শ্রীরাম সাক্তিভেল

Answer 4

অন্যরা যেমন বলেছে, তবে ব্যাতিক্রমগুলিতে ফোকাস করেছে, এটি সত্যই নিয়ন্ত্রণের স্থানান্তরকে অস্পষ্ট পরিচালনা করার বিষয়ে।

আপনার মনে মনে আপনি সম্ভবত এই জাতীয় দৃশ্যের কথা ভাবছেন:

public static object SafeMethod()
{
    foreach(var item in list)
    {
        try
        {
            try
            {
                //do something that won't transfer control outside
            }
            catch
            {
                //catch everything to not throw exceptions
            }
        }
        finally
        {
            if (someCondition)
                //no exception will be thrown, 
                //so theoretically this could work
                continue;
        }
    }

    return someValue;
}

তাত্ত্বিকভাবে, আপনি নিয়ন্ত্রণ প্রবাহটি ট্র্যাক করে বলতে পারেন, হ্যাঁ, এটি "ঠিক আছে"। কোনও ব্যতিক্রম নিক্ষেপ করা হয় না, কোনও নিয়ন্ত্রণ স্থানান্তরিত হয় না। তবে সি # ভাষা ডিজাইনারদের মনে অন্যান্য বিষয় ছিল।

থ্রাউন ব্যতিক্রম

public static void Exception()
{
    try
    {
        foreach(var item in list)
        {
            try
            {
                throw new Exception("What now?");
            }
            finally
            {
                continue;
            }
        }
    }
    catch
    {
        //do I get hit?
    }
}

আতঙ্কিত গোটো

public static void Goto()
{
    foreach(var item in list)
    {
        try
        {
            goto pigsfly;
        }
        finally
        {
            continue;
        }
    }

    pigsfly:
}

ফেরত

public static object ReturnSomething()
{
    foreach(var item in list)
    {
        try
        {
            return item;
        }
        finally
        {
            continue;
        }
    }
}

বিচ্ছেদ

public static void Break()
{
    foreach(var item in list)
    {
        try
        {
            break;
        }
        finally
        {
            continue;
        }
    }
}

তাই উপসংহারে, হ্যাঁ, যখন হয় একটি সামান্য একটি ব্যবহারের সম্ভাবনা continueপরিস্থিতিতে যেখানে নিয়ন্ত্রণ স্থানান্তরিত হচ্ছে না, কিন্তু একটি ভাল চুক্তি মামলার (সংখ্যাগরিষ্ঠ?) ব্যতিক্রম বা জড়িত returnব্লক। ভাষা ডিজাইনার অনুভূত খুব দ্ব্যর্থক এবং (সম্ভবত) অসম্ভব কম্পাইল সময় আপনার এ নিশ্চিত করতে হবে continueব্যবহার করা হয় শুধুমাত্র ক্ষেত্রে যেখানে নিয়ন্ত্রণ প্রবাহ স্থানান্তরিত হচ্ছে না হবে।

Comments

জাভাতে একই অবস্থা পেয়েছিল যখন অবিচ্ছিন্ন হয়ে পড়াশুনা ক্র্যাশ হচ্ছিল। আপনার ব্যাখ্যা বেশ ভাল। সি # সংকলন সময় ত্রুটি দেয় - পুরোপুরি অর্থপূর্ণ।

— দেব_ভিক্রম

Answer 5

ব্লক continueব্যবহার করার সময় সাধারণভাবে তা বোঝা যায় না finally। এক নজর দেখে নাও:

foreach (var item in list)
{
    try
    {
        throw new Exception();
    }
    finally{
        //doesn't make sense as we are after exception
        continue;
    }
}

Comments

"সাধারণভাবে" অনেক কিছুই বোঝায় না। এবং এর অর্থ এই নয় যে এটি "বিশেষত" কাজ করা উচিত নয়। IE: continueলুপ স্টেটমেন্টের বাইরের কোনও ধারণা দেয় না, তবে এর অর্থ এটি সমর্থিত নয়।

— zerkms

আমি মনে করি এটি কিছুটা বোধগম্য। itemফাইল হতে পারে, পড়তে ব্যর্থ -> finallyফাইলটি বন্ধ করে দেয়। continueপ্রক্রিয়াজাতকরণের বাধা দেয়।

— jnovacho

Answer 6

"এটি সংকলন করবে না এবং আমি মনে করি এটি সম্পূর্ণ অর্থবোধ করে"

ঠিক আছে, আমি মনে করি এটি হয় না।

আপনি যখন আক্ষরিক হয়ে থাকেন catch(Exception)তখন আপনার শেষ অবধি প্রয়োজন হয় না (এবং সম্ভবত এটিও নয় continue)।

আপনি যখন আরও বাস্তববাদী হন catch(SomeException), তখন কোনও ব্যতিক্রম ধরা না পড়লে কী ঘটতে হবে? আপনার continueএকপথে যেতে চান, ব্যতিক্রম অন্যটি পরিচালনা করে।

Comments

আমার মনে হয় আপনার finallyযখন দরকার ছিল তখন দরকার ছিল catch। এটি সাধারণত নির্ভরযোগ্য উপায়ে সংস্থানগুলি বন্ধ করার জন্য ব্যবহৃত হয়।

— jnovacho

যদিও এটি কেবল ব্যতিক্রম নয়। আপনার বা ব্লকগুলির মধ্যে সহজেই একটি returnবিবৃতি থাকতে পারে । আমরা এখন কি করব? লুপটি ফিরুন বা চালিয়ে যাবেন? (এবং যদি আমরা অবিরত না, এটা কি পুনরুক্তি করতে শেষ আইটেম যদি তারপর আমরা বাইরে চলতেই থাকবে? এবং বিনিময়ে কখনো ঘটবে?) সম্পাদনা: অথবা এমনকি লুপ বাইরে কোন লেবেলে, প্রায় কাছাকাছি কোনো কর্ম স্থানান্তর বাহিরে নিয়ন্ত্রণ যে লুপ । trycatchforeachgotoforeach

— ক্রিস সিনক্লেয়ার

"আপনি যখন আক্ষরিকভাবে ধরেন (ব্যতিক্রম) তখন আপনার সাথে শেষ হয় না (তবে সম্ভবত অবিরতও নয়)" with আমার যদি কোনও ব্যতিক্রম উত্থাপিত বা না ঘটায় অপারেশন করার দরকার হয় তবে কী হবে?

— এলপালৌব

ঠিক আছে, শেষ পর্যন্ত returnব্লকের ভিতরে অতিরিক্ত গুলি সরবরাহ করে। তবে সাধারণভাবে মৃত্যুদণ্ড কার্যকর হওয়ার পরেও ধরা পড়ে catch

— হেন্ক হলটারম্যান

'অবশেষে' 'ধরা' নয়। এটি ক্লিনআপ কোডের জন্য ব্যবহার করা উচিত। একটি অবশেষে ব্লক একটি ব্যতিক্রম নিক্ষেপ করা হয় বা না তা নির্বিশেষে চলে । স্টাফ ফাইল বন্ধ করে বা মেমরি freeing (আপনি অপরিচালিত কোড ব্যবহার করছি) ইত্যাদি এসব আপনি একটি পরিশেষে ব্লক রাখা হয়

— Robotnik

Answer 7

আপনি অবশেষে ব্লকের শরীর ছেড়ে যেতে পারবেন না। এর মধ্যে বিরতি, ফিরে আসা এবং আপনার ক্ষেত্রে চালিয়ে যাওয়া কীওয়ার্ড অন্তর্ভুক্ত রয়েছে।

Answer 8

finallyব্লক একটি ব্যতিক্রম rethrown হওয়ার জন্য অপেক্ষা করছে সঙ্গে মৃত্যুদন্ড কার্যকর করা যেতে পারে। continueব্যতিক্রমটি পুনর্বিবেচনা না করে (কোনও বা অন্য কোনও কিছু দ্বারা ) ব্লক থেকে বেরিয়ে আসতে সক্ষম হওয়া সত্যিকার অর্থে বোধগম্য হবে না ।

আপনি যদি যাই ঘটে তা আপনার লুপটি চালিয়ে যেতে চান তবে আপনার শেষের বিবৃতিটির দরকার নেই: কেবল ব্যতিক্রমটি ধরুন এবং পুনর্বিবেচনা করবেন না।

Answer 9

finallyএকটি অপ্রকাশিত ব্যতিক্রম নিক্ষেপ করা হয় কিনা তা চালায়। অন্যরা ইতিমধ্যে ব্যাখ্যা করেছে যে এটি কেন continueঅযৌক্তিক করে তোলে , তবে এখানে একটি বিকল্প রয়েছে যা এই কোডটি যা চাচ্ছে বলে মনে হচ্ছে তার মনোভাব অনুসরণ করে। মূলত, finally { continue; }বলছে:

1. যখন ধরা পড়ে ব্যতিক্রম হয়, চালিয়ে যান
2. যখন অপ্রকাশিত ব্যতিক্রম থাকে, তখন সেগুলি নিক্ষেপ করার অনুমতি দিন, তবে এখনও চালিয়ে যান

(1) continueপ্রতিটি শেষে রেখে সন্তুষ্ট হতে পারে catch, এবং (2) পরে নিক্ষেপ করা অসমাপ্ত ব্যতিক্রম সংরক্ষণ করে সন্তুষ্ট হতে পারে। আপনি এটি এভাবে লিখতে পারেন:

var exceptions = new List<Exception>();
foreach (var foo in list) {
    try {
        // some code
    } catch (InvalidOperationException ex) {
        // handle specific exception
        continue;
    } catch (Exception ex) {
        exceptions.Add(ex);
        continue;
    }
    // some more code
}
if (exceptions.Any()) {
    throw new AggregateException(exceptions);
}

প্রকৃতপক্ষে, finallyতৃতীয় ক্ষেত্রেও মৃত্যুদন্ড কার্যকর করা হত, যেখানে ধরা পড়ে বা ধরা পড়ে যায় এমন কোনও ব্যতিক্রম ছিল না। যদি এটি পছন্দসই হয় তবে আপনি অবশ্যই continueপ্রতিটি অভ্যন্তরের পরিবর্তে চেষ্টা-ব্লকের পরে একটি একক রাখতে পারেন catch।

Answer 10

প্রযুক্তিগতভাবে বলতে গেলে এটি অন্তর্নিহিত সিআইএল-এর একটি সীমাবদ্ধতা। ভাষার বিশেষ থেকে :

কন্ট্রোল ট্রান্সফারকে কখনও ব্যতিক্রম হ্যান্ডলিং প্রক্রিয়া বাদে ক্যাচ হ্যান্ডলার বা অবশেষে ধারাটিতে প্রবেশ করার অনুমতি দেওয়া হয় না।

এবং

(ক সংরক্ষিত অঞ্চলের বাইরে কন্ট্রোল স্থানান্তর শুধুমাত্র একটি ব্যতিক্রম নির্দেশ মাধ্যমে অনুমতি দেওয়া হয় leave, end.filter, end.catch, অথবা end.finally)

brনির্দেশের জন্য ডক পৃষ্ঠায় :

চেষ্টা, ধরা, ফিল্টার এবং অবশেষে ব্লকগুলিতে এবং এর বাইরে স্থানান্তর নিয়ন্ত্রণ করুন এই নির্দেশনা দ্বারা সম্পাদন করা যাবে না।

এই শেষ জন্য কথা সত্য সব শাখা নির্দেশাবলী সহ beq, brfalseইত্যাদি

Answer 11

নিয়ন্ত্রণের স্থানান্তর দ্বারা অবশেষে অবরুদ্ধ হওয়া শব্দার্থক শব্দটির ডিজাইনাররা (বা পারেনি) কারণ চাননি।

একটি সমস্যা বা সম্ভবত মূল সমস্যাটি হ'ল finallyব্লকটি কিছু অ-স্থানীয় নিয়ন্ত্রণ স্থানান্তর (ব্যতিক্রম প্রক্রিয়াজাতকরণ) এর অংশ হিসাবে কার্যকর করা হয় exec যে নিয়ন্ত্রণ স্থানান্তর লক্ষ্য লক্ষ্য বদ্ধ লুপ নয়; ব্যতিক্রম প্রক্রিয়াকরণ লুপটি বাতিল করে এবং আরও অযত্নে চালিয়ে যায়।

যদি আমাদের finallyক্লিনআপ ব্লকের বাইরে কোনও নিয়ন্ত্রণ স্থানান্তর থাকে তবে মূল নিয়ন্ত্রণ স্থানান্তরটি "হাইজ্যাক" করা হচ্ছে। এটি বাতিল হয়ে যায়, এবং নিয়ন্ত্রণ অন্য কোথাও চলে।

শব্দার্থক কাজ করা যেতে পারে। অন্যান্য ভাষাগুলিতে এটি আছে।

সি # এর ডিজাইনাররা স্থির, "গোটো-মত" নিয়ন্ত্রণের স্থানান্তরকে অস্বীকার করার সিদ্ধান্ত নিয়েছিলেন, যার ফলে কিছুটা সহজ করে দেওয়া হয়েছে।

যাইহোক, আপনি এটি করলেও এটি কোনও থেকে ডায়নামিক ট্রান্সফার শুরু হলে কী হয় সে প্রশ্নটি সমাধান করে না finally: শেষ অবধি যদি কোনও ফাংশন কল করে এবং সেই ফাংশনটি ছুড়ে ফেলে তবে কী হবে? মূল ব্যতিক্রম প্রক্রিয়াটি তখন "হাইজ্যাক করা" হয় "

আপনি যদি এই হাইজ্যাকিংয়ের দ্বিতীয় ধরণের শব্দার্থবিজ্ঞানের কাজ করেন তবে প্রথম ধরণের নিষেধাজ্ঞার কোনও কারণ নেই। এগুলি আসলে একই জিনিস: একটি নিয়ন্ত্রণ স্থানান্তর হ'ল একটি নিয়ন্ত্রণ স্থানান্তর, এটি একই লেজিকাল স্কোপ বা না থাকুক।

Comments

পার্থক্য যে finallyসংজ্ঞা দ্বারা আবশ্যক অবিলম্বে (একটি uncaught ব্যতিক্রম স্থানান্তর এটি আলোড়ন সৃষ্টি অব্যাহত দ্বারা অনুসরণ করা return, ইত্যাদি)। "গোটো-সদৃশ" স্থানান্তরগুলির মধ্যে অনুমতি দেওয়া সহজ হবে finally(কোন ভাষাগুলি উপায় দ্বারা এটি করে?) তবে এটি করার অর্থ এই যে try { return } finally { ... } ফিরে না আসতে পারে , যা সম্পূর্ণ অপ্রত্যাশিত। যদি এমন finallyকোনও ফাংশন কল করে যা ছুড়ে ফেলে, এটি আসলে একই জিনিস নয়, কারণ আমরা ইতিমধ্যে প্রত্যাশা করি যে ব্যতিক্রমগুলি যে কোনও সময় ঘটতে পারে এবং স্বাভাবিক প্রবাহকে বাধা দেয়।

— nmclean

@ এনমক্লান: আসলে, একটি ব্যতিক্রম যা পালিয়ে যায় finallyতা হ'ল ধরণের জিনিস, যার ফলে এটি অপ্রত্যাশিত এবং অযৌক্তিক প্রোগ্রাম প্রবাহের ফলে ঘটতে পারে। পার্থক্যটি হ'ল ভাষা ডিজাইনাররা, এমন সব প্রোগ্রামকে প্রত্যাখ্যান করতে অক্ষম হচ্ছেন যেখানে শেষ অবধি ব্লকটি একটি অপ্রত্যাশিত ব্যতিক্রম ছুঁড়ে ফেলতে পারে, পরিবর্তে এই জাতীয় প্রোগ্রামগুলিকে সংকলন করতে দেয় এবং আশা করে যে প্রোগ্রামটি এমন কোনও পরিণতি গ্রহণ করতে পারে যা পূর্ববর্তী ব্যতিক্রম-পরিত্যাগকে অনুসরণ করতে পারে ক্রম.

— সুপারক্যাট

@ সুপের্যাট আমি সম্মত হই যে এটি প্রত্যাশিত প্রবাহকে ভঙ্গ করে, তবে আমার বক্তব্যটি হ'ল চলমান প্রবাহটি একটি হোক বা না থাকুক, সর্বদা অনাহীন ব্যতিক্রমগুলির ক্ষেত্রে এটিই হয় finally। কাজীর শেষ অনুচ্ছেদের যুক্তি অনুসারে, ফাংশনগুলি তাদের কলারের ক্ষেত্রে প্রবাহকে continueইত্যাদির দ্বারা প্রভাবিত করতেও নিখরচায় হওয়া উচিত , কারণ তাদের ব্যাতিক্রমের দ্বারা এটি করার অনুমতি দেওয়া হয়। তবে অবশ্যই এটি অনুমোদিত নয়; ব্যতিক্রমগুলি এই নিয়মের একমাত্র ব্যতিক্রম, তাই নামটি "ব্যতিক্রম" (বা "বাধা") রাখে।

— nmclean

@ এনএমক্লান: অ-নেস্টেড ব্যতিক্রমগুলি একটি নিয়ন্ত্রণ প্রবাহকে প্রতিনিধিত্ব করে যা সাধারণ সম্পাদন থেকে পৃথক, তবে এখনও কাঠামোগত। কোনও ব্লকের নিম্নলিখিত বিবৃতি কেবল তখনই কার্যকর করা উচিত যদি block ব্লকের মধ্যে উপস্থিত সমস্ত ব্যতিক্রমগুলি এর মধ্যে ধরা পড়ে। এটি যুক্তিসঙ্গত প্রত্যাশার মতো মনে হতে পারে তবে কোনও finallyব্লকের মধ্যে ঘটে যাওয়া ব্যতিক্রম এটি লঙ্ঘন করতে পারে। সত্যিই একটি বাজে পরিস্থিতি, যা আইএমএইচওকে ন্যূনতম finallyযে কোনও ব্যতীত ব্যতিক্রম সম্পর্কে অবহিত করতে দিয়ে ব্লকগুলি সমাধান করা উচিত ছিল যাতে তারা সম্মিলিত ব্যতিক্রম সামগ্রী তৈরি করতে পারে।

— সুপারক্যাট

@ মিম্কেলান দুঃখিত, আমি সম্মত নই যে "ব্যতিক্রম" নামটি "নিয়মের ব্যতিক্রম" (নিয়ন্ত্রণ সম্পর্কিত) সি #, এলওএল সম্পর্কিত নির্দিষ্ট থেকে এসেছে comes একটি ব্যতিক্রমের নিয়ন্ত্রণ প্রবাহ পরিবর্তনের দিকটি হ'ল একটি অ-স্থানীয় গতিশীল নিয়ন্ত্রণ স্থানান্তর। একই লেজিকাল স্কোপের অভ্যন্তরে নিয়মিত নিয়ন্ত্রণ স্থানান্তর (অবাঞ্ছিত ঘটনা ঘটছে না) এর একটি বিশেষ কেস হিসাবে বিবেচিত হতে পারে।

— কাজ