খালি ক্যাচ স্টেটমেন্ট পাওয়া কি কখনও ঠিক হবে?

Question

আমি এটি সম্পর্কে ভেবেছিলাম এবং উদাহরণ দিয়ে আসতে পারিনি। কেউ কেন একটি ব্যতিক্রম ধরা এবং এটি সম্পর্কে কিছুই করতে চাইবে? আপনি কি একটি উদাহরণ দিতে পারেন? হয়তো এটি এমন কিছু যা কখনও করা উচিত নয়।

Comments

শেষ পর্যন্ত কি?

— ক্রিস

বিটিডব্লিউ - এটি গত বছর এসও তে জিজ্ঞাসা করা হয়েছিল: stackoverflow.com/questions/1234343/…

— ওয়ারেন

এটি খালি কেন এটিতে কমপক্ষে একটি মন্তব্য থাকা উচিত ।

— পিটারচেন

Answer 1

আমি ডি তে রূপান্তর ত্রুটির মতো জিনিসগুলি দিয়ে সর্বদা এটি করি:

import std.conv, std.stdio, std.exception;

void main(string[] args) {  
    enforce(args.length > 1, "Usage:  foo.exe filename");

    double[] nums;

    // Process a text file with one number per line into an array of doubles,
    // ignoring any malformed lines.
    foreach(line; File(args[1]).byLine()) {
        try {
            nums ~= to!double(line);
        } catch(ConvError) {
            // Ignore malformed lines.
        }
    }

    // Do stuff with nums.
}

এটি বলেছিল, আমি মনে করি যে সমস্ত ক্যাপ ব্লকগুলির মধ্যে কিছু থাকা উচিত , এমনকি যদি কিছু আপত্তি থাকে তবে কেন আপনি ব্যতিক্রম উপেক্ষা করছেন তা ব্যাখ্যা করে।

সম্পাদনা: আমি এটিতেও জোর দিতে চাই, আপনি যদি এই জাতীয় কিছু করতে চলেছেন তবে আপনি যে নির্দিষ্ট ব্যতিক্রমটি উপেক্ষা করতে চান কেবল সেটিকে ধরতে আপনার সাবধান হওয়া উচিত। পুরানো সরল catch {}কাজ করা প্রায়শই একটি খারাপ কাজ।

Comments

ব্যাখ্যা মন্তব্যের জন্য +1।

— মাইকেল কে

কিছু আইডিই আপনাকে উল্লেখ করতে দেয় যে ব্যতিক্রমের জন্য একটি নির্দিষ্ট নাম (সাধারণত "উপেক্ষা") ইঙ্গিত দেয় যে আপনি ইচ্ছাকৃতভাবে এটিকে উপেক্ষা করছেন, যা অন্যথায় প্রদর্শিত সতর্কতাকে দমন করে; এটি মন্তব্যের জায়গা নেয়।

— অ্যালেক্স ফেনম্যান

আমি ডি পরিচিত নই, তবে আমি ধরে নিয়েছি বুল ট্রাইপার্স (স্ট্রিং লাইন, ডাবল ভলটোপার্স আউট) এর মতো কিছু করা সম্ভব, যা পরিষ্কার হতে পারে।

— ysolik

বাহ, আসলে কে ডি ব্যবহার করে! :

— জেমস ম্যাকনেলিস

@ মিচেল বলেছেন - আপনি মন্তব্যটি পেয়েছেন বলে এটি একেবারেই খালি নয় ; যদি বিবৃতি না পাওয়া যায় তবে "এই ধরাটি ইচ্ছাকৃতভাবে ফাঁকা ছেড়ে দেওয়া" মন্তব্য যুক্ত করা বাধ্যতামূলক হওয়া উচিত

— STW

Answer 2

একটি উদাহরণ যেখানে আমি মনে করি ঠিক আছে কিছু না করে ব্যতিক্রম গিলে ফেলা ঠিক নয়, এমনকি ব্যতিক্রম লগ করাও লগিং কোডের অভ্যন্তরে।

আপনি যদি কিছু লগ ইন করার চেষ্টা করে থাকেন এবং ব্যতিক্রম পেয়ে থাকেন তবে এটির বিষয়ে আপনি বেশি কিছু করতে পারবেন না:

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

এটি আপনাকে চুপচাপ এটিকে গ্রাস করার, "অ্যাপ্লিকেশনটির মূল কাজটি সম্পাদন করার অনুমতি দেয়, তবে এটির সমস্যা সমাধানের ক্ষমতা নিয়ে আপস করে" এর "সর্বনিম্নতম মন্দ" বিকল্পটি দেয়।

Comments

দুর্দান্ত পয়েন্ট ডিবাগিং কোডটি সর্বদা একটি চ্যালেঞ্জ।

— দেবসোলো

এটি, এক মিলিয়ন বার। বিশেষত যখন আপনি বিবেচনা করেন যে আপনি যদি লগইন করছেন তবে আপনি ভয়াবহ অবস্থায় থাকতে পারেন; আপনি স্মৃতি থেকে দূরে থাকতে পারেন, ক্র্যাশ হতে পারে, কিছু হতে পারে। এই মুহুর্তে, আপনি যখন কোনও ত্রুটি লগইন করছেন এবং এটি ব্যর্থ হয় তখন একমাত্র দায়বদ্ধ কাজটি কিছুই হয় না; আপনার কোনও গ্যারান্টি নেই যে আপনি চেষ্টা করে যা কিছু তা খারাপ করে না।

— GWLlosa

দুর্দান্ত পয়েন্ট। আমার লগিং কোডে, আমি ব্যতিক্রমের জন্য InnerMessage যুক্ত করতে চাই। অনেক সময় এটি শূন্য হয়, সুতরাং এটি যুক্ত করার চেষ্টা করলে লগইনটি নিজেই ফুঁসে উঠবে।

— টাঙ্গুরেনা

@ টাঙ্গুরেেন যদি এটি প্রায়শই নালাগুলি হয় তবে তা পরিচালনা করুন, ফুঁকুন না। সি # তে আমি প্রায়শই এই জাতীয় জিনিসগুলি রক্ষা করি ?? "";

— লরেন পেচটেল

Answer 3

যদি কোনও ব্যতিক্রম কোনও অপারেশন দ্বারা ছুঁড়ে দেওয়া হয় যা যাইহোক alচ্ছিক ছিল, তখন করার মতো কিছুই হতে পারে না। এটি লগ করা দরকারী নাও হতে পারে। সেক্ষেত্রে আপনি হয়ত এটি ধরতে চান এবং কিছুই করতে পারেন না।

আপনি যদি এটি করছেন তবে একটি মন্তব্য অন্তর্ভুক্ত করুন। সবসময় যে কোনও বাগের মতো মনে হয় এমন মন্তব্য করুন (একটি switchবিবৃতিতে পতিত হওয়া , খালি catchব্লক, শর্তে অ্যাসাইনমেন্ট)।

আপনি তর্ক করতে পারেন যে এটি ব্যতিক্রমগুলির যথাযথ ব্যবহার নয়, তবে এটি অন্য প্রশ্নের জন্য।

Answer 4

খালি catchব্লকগুলি বেশিরভাগ ভাষায় কোড গন্ধ। মূল ধারণাটি ব্যতিক্রমী পরিস্থিতিতে ব্যতিক্রমগুলি ব্যবহার করা এবং তাদের যৌক্তিক নিয়ন্ত্রণের জন্য ব্যবহার না করা। সমস্ত ব্যতিক্রম অবশ্যই কোথাও পরিচালনা করতে হবে।

এই পদ্ধতির গ্রহণের ফলস্বরূপ, আপনি যখন একটি নির্দিষ্ট অ্যাপ্লিকেশন স্তর প্রোগ্রাম করেন, আপনার বেশ কয়েকটি পছন্দ থাকে:

• ব্যতিক্রম সম্পর্কে কিছুই করবেন না। এটি ধরা পড়ে এবং একটি ভিন্ন স্তর দ্বারা পরিচালিত হবে
• এটি ধরুন এবং সংশোধনমূলক ক্রিয়াটি করুন।
• এটি ধরুন, কিছু করুন, তবে অন্য স্তরটিকে হ্যান্ডেল করার জন্য এটি আবার ফেলে দিন

এটি সত্যিকার অর্থে কোনও কিছুই করার নেই, খালি catchব্লক রয়েছে।

সংযোজন সম্পাদনা : ধরুন আপনি এমন একটি ভাষায় প্রোগ্রামিং করছেন যেখানে ব্যতিক্রম ছোঁড়াটাই প্রোগ্রাম লজিক (বিকল্পগুলির মধ্যে একটি goto) নিয়ন্ত্রণের স্বাভাবিক উপায় । তারপরে catchএই ভাষায় লিখিত প্রোগ্রামে একটি খালি elseব্লক অনেকটা aতিহ্যবাহী ভাষায় খালি ব্লকের মতো (বা কোনও elseব্লক নয়)। তবে আমি বিশ্বাস করি এটি সি #, জাভা বা সি ++ উন্নয়ন সম্প্রদায়ের দ্বারা প্রস্তাবিত প্রোগ্রামিং স্টাইল নয়।

Comments

আমি মনে করি লজিক নিয়ন্ত্রণ ব্যতিক্রম হিসাবে ব্যতিক্রমগুলি ব্যবহার করা মোটামুটি সাধারণ হয়ে গেছে, তাই আমি প্রায়শই খালি বা প্রায় খালি ক্যাচ ব্লক সহ নিজেকে পাই।

— হোয়াটসাইম রাখুন

খালি ক্যাচ ব্লকটি প্রবাহ নিয়ন্ত্রণের ক্ষেত্রে ব্যতিক্রমগুলির ইঙ্গিত দিতে পারে তা শনাক্ত করার জন্য +1 ।

— জন এম গ্যান্ট

প্রোগ্রামিং লজিকের ব্যতিক্রমগুলি ব্যবহার করা সাধারণত খারাপ অভ্যাস হিসাবে বিবেচিত হয়। তবে, আশ্চর্যরূপে (ব্যতিক্রমগুলির বিরুদ্ধে আমার মূল যুক্তি) ব্যতিক্রমগুলিতে একটি লক্ষণীয় পারফরম্যান্স হিট আসে না। কোডেপ্রজেক্ট / কেবি / এক্সসেপশন / এক্সেকশনপিরফরমেন্স.এএসপিএক্স দেখুন ।

— ইভান প্লেইস

Answer 5

কিছু ক্ষেত্রে, জাভা আপনাকে এমন একটি ব্যতিক্রম পরিচালনা করতে হবে যা একেবারে কোনও পরিস্থিতিতে, কখনও ঘটতে পারে না। এই কোডটি বিবেচনা করুন:

try {
   bytes[] hw = "Hello World".getBytes("UTF-8");
}
catch(UnsupportedCodingException e) {
}

জাভা প্ল্যাটফর্মের প্রতিটি প্রয়োগের জন্য নিম্নলিখিত মানক অক্ষরগুলি সমর্থন করা প্রয়োজন।

...

হল UTF-8

আপনার জাভা প্ল্যাটফর্মটি ভেঙে না ফেলে, কখনও কখনও এই ব্যতিক্রম ঘটানোর উপায় নেই। তাহলে কেন এটি সামলাতে বিরক্ত করবেন? তবে আপনি চেষ্টা-ধরার-ধারাটি কেবল বাদ দিতে পারবেন না।

Comments

এর মতো ক্ষেত্রে আমি throw new Error(e)কেবলমাত্র কিছু মিস করিনি (বা আসলে ভাঙা প্ল্যাটফর্মের প্রতিবেদন করুন) তা নিশ্চিত হওয়ার জন্য যুক্ত করার প্ররোচিত করব।

— হ্যালি নাসট

@ হ্যালকন্যাস্ট হ্যাঁ এটি এখানে পুরো বিশদে আলোচনা করা হয়েছে: সফ্টওয়্যারেনজেনারিং.স্ট্যাকেক্সেঞ্জার.কমেসেশনস

— 122233/…

Answer 6

একটি সাধারণ নিয়ম হিসাবে, না। আপনি হয় ব্যতিক্রমটিকে স্ট্যাকের উপরে ফেলে দিতে চান, বা যা হয়েছে তা লগ করুন।

যাইহোক, আমি প্রায়শই এটি করি যখন আমি স্ট্রিংগুলি পার্সিং করে সংখ্যায় রূপান্তর করি (বিশেষত ম্যাপিং প্রকল্পগুলিতে যা একবারে ব্যবহার হয় এবং বিভিন্ন ধরণের হয়)।

boolean isNonZeroNumber = false;

try {
   if(StringUtils.isNotBlank(s) && new BigDecimal(s).compareTo(BigDecimal.ZERO) != 0) {
     b = true;
   }
} catch(NumberFormatException e) {
//swallow this exception; b stays false.
}

return b;

Answer 7

কিছু ক্ষেত্রে ব্যতিক্রম মোটেও ব্যতিক্রমী নয়; আসলে, এটি প্রত্যাশিত এই উদাহরণ বিবেচনা করুন:

    /* Check if the process is still alive; exitValue() throws an exception if it is */
    try {
        p.exitValue();
        processPool.remove(p);
    }
    catch (IllegalThreadStateException e) { /* expected behaviour */ }

যেহেতু জাভা.লং.প্রসেস () তে কোনও আইলাইভ () পদ্ধতি নেই তাই এটি এখনও বেঁচে আছে কিনা তা যাচাই করার একমাত্র উপায় হ'ল এক্সটিভালিউ () কল করা, যা প্রক্রিয়াটি এখনও চলমান থাকলে অবৈধ ট্র্যাডস্টেট এক্সেকশন নিক্ষেপ করে।

Answer 8

আমার নম্র অভিজ্ঞতায় খুব ভালই এই ভাল জিনিস হয়। আপনার মাইলেজ যদিও আলাদা হতে পারে।

প্রায়শই আমি যখনই এটি আমাদের কোড বেসে দেখেছি, এটি হয়েছে কারণ আমি খাওয়া ব্যতিক্রম লুকিয়ে থাকা একটি বাগ সন্ধান করেছি। অন্য কোনও উপায়ে বলতে গেলে, কোনও কোড সরবরাহ না করে, অ্যাপ্লিকেশনটির কোনও ত্রুটি চিহ্নিত করার বা অন্য ক্রিয়া সম্পাদনের কোনও উপায় নেই।

কখনও কখনও, উদাহরণস্বরূপ, এপিআই স্তরগুলিতে আপনি ব্যাতিক্রমগুলি অতীত হতে দিতে বা সক্ষম করতে নাও পারেন, সুতরাং সেই ক্ষেত্রে আমি সবচেয়ে জেনেরিক চেষ্টা করার চেষ্টা করি এবং তারপরে লগইন করি। আবারও, কমপক্ষে একটি ডিবাগ / ডায়াগনোশন সেশনের সুযোগ দেওয়ার জন্য।

সাধারণত, যদি এটি অবশ্যই খালি থাকে, তবে আমি কমপক্ষে কোনও প্রকারের একটি দৃ put়তা রেখেছি, তাই কোনও ডিবাগ সেশনের সময় কমপক্ষে কিছু ঘটে। এটি বলেছিল, আমি যদি এটি পরিচালনা করতে না পারি তবে আমি সেগুলি সম্পূর্ণরূপে বাদ দিতে চাই।

Answer 9

আইএমওর এমন এক জায়গা আছে যেখানে খালি ক্যাচ স্টেটমেন্ট ঠিক আছে। পরীক্ষার ক্ষেত্রে যেখানে আপনি ব্যতিক্রম প্রত্যাশা করেন:

try
{
   DoSomething(); //This should throw exception if everything works well
   Assert.Fail('Expected exception was not thrown');
}
catch(<whatever exception>)
{
    //Expected to get here
}

Comments

+1, আমি ঘৃণা করি যে আমি এটি করি তবে এটি জুনেটে কাজ করে

— সাল

@ সাল: @ টেস্ট (প্রত্যাশিত = এক্সপেশন.class) সম্পর্কে কী?

— ysolik

@ আইসোলিক, খারাপ অভ্যাস

— সাল

@ সল: কেন এটি খারাপ অভ্যাস?

— অ্যাডাম লিয়ার

ummmm। ইউনিট টেস্টিং ফ্রেমওয়ার্কের সাথে এটি করার উপায় রয়েছে। যাত্রা। NUnit। কিছু কিছু ক্ষেত্রে রয়েছে যেখানে পরীক্ষামূলকভাবে কিছু ব্যর্থ হয় তা পরীক্ষা করা কার্যকর হতে পারে। যদিও, আমি প্রযোজনা কোডে এটি কখনই করব না।

— ইভান প্লেইস

Answer 10

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

Answer 11

কোনও ব্যতিক্রম ঘটলে আমি কিছুটা সতর্কতা না থাকাতে বিশ্বাস করি না - প্রোগ্রামিংয়ের একটি লক্ষ্য কোডের উন্নতি হওয়া উচিত না? যদি 10% সময় ব্যতিক্রম ঘটে এবং আপনি কখনই এটি সম্পর্কে জানেন না, তবে ব্যতিক্রমটি সর্বদা খারাপ বা আরও খারাপ হবে।

যাইহোক, আমি অন্য দিকটি দেখতে পাচ্ছি, যদি ব্যতিক্রম কোডের প্রক্রিয়াকরণে কোনও সত্যিকারের ক্ষতি না করে তবে ব্যবহারকারীকে কেন এটি প্রকাশ করুন। আমি যে সমাধানটি সাধারণত প্রয়োগ করি তা হ'ল এটি আমার লগার ক্লাস দ্বারা লগ করা হয় (এটি আমি যে কোনও একক শ্রেণীর মধ্যে কাজ করে যা লিখি)।

যদি এটি সৌম্য ব্যতিক্রম হয় তবে আমি আমার লগারের .Debug () পদ্ধতিতে কল করব; অন্যথায়, লগার.অরার () (এবং (সম্ভবত) নিক্ষেপ)

try
{
   doWork();
}
catch(BenignException x)
{
  _log.Debug("Error doing work: " + x.Message);
}

যাইহোক, আমার লগার প্রয়োগের ক্ষেত্রে, .Debug () পদ্ধতিতে কল করার পরে কেবলমাত্র এটিই লগ হবে যদি আমি আমার App.Config ফাইলটি নির্দিষ্ট করে যে প্রোগ্রামের প্রয়োগের লগ স্তরটি ডিবাগ মোডে রয়েছে।

Comments

_ লগ.ডিবগ একটি ব্যতিক্রম ছোঁড়ে (যদি কোনও কারণে)?

— 19

তারপরে .দেবগ () ব্যতিক্রম খায় এবং আমি এটি সম্পর্কে কখনই জানতে পারি না। তবে কোডটি সম্পর্কে প্রায়শই ব্যতিক্রম ছুঁড়ে মারার চেয়ে আমি আমার লগার সম্পর্কে অনেক বেশি আত্মবিশ্বাসী বোধ করি। যদি আমি এই বিষয়ে উদ্বিগ্ন হয়ে থাকি তবে আমি মনে করি যে আমি কোনও ধরণের প্যাটার্ন প্রয়োগ করতে পারি যা ক্যাচ ব্লকে প্রবেশের জন্য নজর রাখে এবং এটি পরে সংরক্ষণ করে। যাই হোক না কেন - পয়েন্ট নেওয়া

— টিম ক্ল্যাসন

Answer 12

অস্তিত্ব পরীক্ষা করা ভাল ব্যবহারের ক্ষেত্রে:

// If an exception happens, it doesn't matter. Log the initial value or the new value

function logId(person) {
    let id = 'No ID';
    try {
        id = person.data.id;
    } catch {}
    console.log(id);
}

আর একটি মামলা হ'ল যখন একটি finallyধারা ব্যবহার করা হয়:

 function getter(obj){}

 function objChecker()
   {
   try
     {
     /* Check argument length and constructor type */
     if (getter.length === 1 && getter.constructor === Function)
       {
       console.log("Correct implementation");
       return true;
       }
     else
       {
       console.log("Wrong implementation");
       return false;
       }
     }
   catch(e)
     {
     }
   finally
     {
     console.log(JSON.stringify(getter))
     }
   }

 // Test the override of the getter method 
 getter = getter;
 objChecker();
 getter = [];
 objChecker();
 getter = {};
 objChecker();
 getter = RegExp;
 objChecker();
 getter = Function;
 objChecker();

ECMAScript এ ক্যাচ বাইন্ডিং কে বাদ দেওয়ার অনুমতি দেওয়ার প্রস্তাব রয়েছে যা এই এবং অনুরূপ ব্যবহারের ক্ষেত্রে সম্পর্কিত।

তথ্যসূত্র

• ইএস প্রস্তাবনা: alচ্ছিক ধরা বাঁধাই

• পাইথন - কীভাবে ব্যতিক্রমগুলি যথাযথভাবে উপেক্ষা করা যায় - স্ট্যাক ওভারফ্লো

• প্রতিশ্রুতি প্রতিরোধের নিদর্শনগুলি · পেটাক্যান্টনভ / ব্লুবার্ড উইকি · গিটহাব

• জাভাস্ক্রিপ্ট ওভাররাইড প্যাটার্নগুলি

• জাভাস্ক্রিপ্ট - বর্তমান স্ক্রিপ্ট লোড উপর স্ক্রিপ্ট চালানো - স্ট্যাক ওভারফ্লো

Comments

আর একটি উদাহরণ: নোডেজে, fs.axists পদ্ধতি (যা সত্য বা মিথ্যা প্রত্যাবর্তন করে ) fs.access এর পক্ষে অবহিত করা হয় ( nodejs.org/dist/latest-v10.x/docs/api/… ) যা একটি ব্যতিক্রম ছুঁড়ে যদি একটি ফাইল উপস্থিত না থাকে। ফাইল উপস্থিত থাকলে কেউ যদি কিছু করতে চায় তবে ক্যাচ ক্লজটি সম্পূর্ণ অপ্রয়োজনীয়।

— সিস্টেমেভিচ

Answer 13

কনসোল অ্যাপ্লিকেশনটির জন্য লগিং ক্লাসের সাথে এই জাতীয় কিছু করার জন্য কেবলমাত্র আমার প্রয়োজন হয়েছিল। একটি শীর্ষ-স্তরের গ্লোবাল ক্যাচ হ্যান্ডলার ছিল যা STDOUT এ ত্রুটিটি নির্গমন করেছিল, কোনও ফাইলটিতে ত্রুটিটি লগইন করেছে, তারপরে>> 0 টি ত্রুটি কোড সহ অ্যাপটি বন্ধ করে দিয়েছে।

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

যদি আপনি কিছু চেষ্টা}} ব্লকগুলি বাদ দেন তবে আপনি বার্তা বাক্সে উপস্থিত ব্যতিক্রমটি শেষ করতে পারেন (নীরব কনফিগার অ্যাপ্লিকেশনটির জন্য যা চান তা নয়)। সুতরাং যে পদ্ধতিতে লগ ফাইল লিখতে, আমার একটি খালি ক্যাচ হ্যান্ডলার আছে। আপনি তবুও 0 টি ত্রুটি কোড পান বলে এটি ত্রুটিটিকে সমাহিত করে না, এটি কেবল অসীম লুপটি থামিয়ে দেয় এবং অ্যাপটিকে সুদৃ .়ভাবে প্রস্থান করতে দেয়।

এটি খালি কেন তা ব্যাখ্যা করে অবশ্যই একটি মন্তব্য আছে।

(আমি এটি আগে পোস্ট করতে যাচ্ছিলাম, আমি কেবল বিস্মৃত হওয়ার ভয়ে ভীত ছিলাম। যেহেতু আমি একমাত্র নই, যদিও ...)

Answer 14

এটি পরিস্থিতিতে ঠিক আছে যখন বেশিরভাগ সমালোচনামূলক টুকরোটি শেষে থাকুক না কেন কিছু ক্রম অবশ্যই কার্যকর করা উচিত exec

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

Comments

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

— লরেন পেচটেল

Answer 15

ত্রুটি থেকে পুনরুদ্ধার করার জন্য সিস্টেমের সংস্থানগুলি গ্রেফতার করে বন্ধ করা

এই ক্ষেত্রে. আপনি যদি ব্যাকগ্রাউন্ডে এমন কোনও পরিষেবা চালাচ্ছেন যা ব্যবহারকারীর প্রতিক্রিয়া দেয় না, আপনি ব্যবহারকারীর কাছে ত্রুটির একটি ইঙ্গিত দিতে না চাইতে পারেন তবে আপনাকে প্রশংসাপূর্ণ পদ্ধতিতে ব্যবহার করা সংস্থানগুলি বন্ধ করতে হবে।

try
{
    // execution code here
}
catch(Exception e)
{
    // do nothing here
}
finally
{
    // close db connection
    // close file io resource
    // close memory stream
    // etc...
}

আদর্শভাবে, আপনি ত্রুটিগুলি ধরার জন্য ডিবাগ মোডে ক্যাচটি ব্যবহার করতে এবং এগুলি কনসোলে বা পরীক্ষার জন্য কোনও লগ ফাইলে মুদ্রণ করতে চান। উত্পাদনের পরিবেশে, ব্যাকগ্রাউন্ড পরিষেবাদি সাধারণত কোনও ত্রুটি নিক্ষেপ করার সময় ব্যবহারকারীকে বাধা দেয় না বলে আশা করা হয় যাতে ত্রুটির আউটপুট দমন করা উচিত।