সাধারণ ব্যতিক্রমগুলি ধরা কি আসলেই খারাপ জিনিস?

56

আমি সাধারণত বেশিরভাগ কোড বিশ্লেষণ সতর্কতাগুলির সাথে একমত হই এবং আমি সেগুলি মেনে চলার চেষ্টা করি। তবে, এইটির সাথে আমার আরও কঠিন সময় কাটাচ্ছে:

CA1031: সাধারণ ব্যতিক্রম ধরণগুলি ধরবেন না

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

উদাহরণস্বরূপ, যদি ফু বার বার কল করে এবং ফু দ্বারা বার দ্বারা নিক্ষেপ করা ব্যতিক্রমের প্রকারটি নির্বিশেষে প্রক্রিয়াজাতকরণ বন্ধ করা দরকার, তবে আমি যে ধরণের ব্যতিক্রম ধরছি সে সম্পর্কে সুনির্দিষ্ট হওয়ার কোনও সুবিধা আছে কি?

এর থেকে আরও ভাল উদাহরণ হতে পারে:

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

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

c# design exceptions

— বব হর্ন
সূত্র

12

কি হবে OutOfMemoryException? সব কিছুর মত একই হ্যান্ডলিং কোড?

— প্যাট্রিক

@ পেট্রিক ভাল পয়েন্ট। আপনার প্রশ্নটি কভার করতে আমি আমার প্রশ্নের মধ্যে একটি নতুন উদাহরণ যুক্ত করেছি।

— বব হর্ন

1

আপনার ব্যাক্তিদের কী করা উচিত সে সম্পর্কে সাধারণ বিবৃতি দেওয়ার মতো সাধারণ ব্যতিক্রমগুলি ধরা। সব কিছুর ক্ষেত্রে সাধারণত কোনও এক-আকারের-ফিট হয় না approach

4

@ পেট্রিক যা হবেন OutOfMemoryError, যা Exceptionউত্তরাধিকার গাছ থেকে সেই কারণেই পৃথক

— দারখোগ

Ctrl-Alt-Del এর মতো কীবোর্ড ব্যতিক্রম সম্পর্কে কী বলা যায়?

— মাওগ

33

এই নিয়মগুলি সাধারণত একটি ভাল ধারণা এবং সুতরাং এটি অনুসরণ করা উচিত।

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

তর্কটির পাল্টা দিকে।

এটির জন্য ভাল পরিস্থিতি হিসাবে আমি আপনার উদাহরণটি উপরে দেখছি না। যদি লগিং সিস্টেমটি ব্যর্থ হয় (সম্ভবত কিছু অন্য ব্যতিক্রম লগইন করা হয়) তবে আমি সম্ভবত আবেদনটি চালিয়ে যেতে চাই না। আউটপুট থেকে ব্যতিক্রম প্রিন্ট করুন এবং মুদ্রণ করুন যাতে ব্যবহারকারী দেখতে পায় কী ঘটেছিল।

— মার্টিন ইয়র্ক
সূত্র

2

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

— শাদুর

6

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

— মগ

1

আকর্ষণীয়, লগ 4 নেট স্পষ্টভাবে অ্যাপটি থামাতে চায় না কেবল লগিং ব্যর্থ হওয়ার কারণে। এবং আমি মনে করি এটি আপনি লগইন করছেন তার উপর নির্ভর করে; সুরক্ষা নিরীক্ষণ, অবশ্যই, প্রক্রিয়াটি হত্যা। কিন্তু লগ লগ? যে গুরুত্বপূর্ণ নয়।

— অ্যান্ডি

1

@ অ্যান্ডি: হ্যাঁ সবকিছু আপনি যা করছেন তার উপর নির্ভর করে।

— মার্টিন ইয়র্ক

2

আপনি তাদের বুঝতে পারছেন না কেন? এবং আপনি কি এটা করার চেষ্টা করা উচিত নয়?

— মাগগ

31

হ্যাঁ, সাধারণ ব্যতিক্রম ধরা খুব খারাপ জিনিস। একটি ব্যতিক্রমের অর্থ হ'ল প্রোগ্রামটি যা করতে বলেছিল তা করতে পারে না।

কয়েকটি ব্যতিক্রম রয়েছে যা আপনি পরিচালনা করতে পারেন :

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

ওহ, এবং একটি সাধারণ নিয়ম হিসাবে: আপনি যদি এটি ধরেন তবে কোনও ব্যতিক্রম কী করতে হবে তা যদি আপনি না জানেন তবে কেবলমাত্র দ্রুত ব্যর্থ হওয়া ভাল (কলারের ব্যতিক্রমটি পাস করুন এবং এটি পরিচালনা করুন)

— ভিক্টর হুরদুগাচি
সূত্র

1

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

— সুইভ

4

পরিবর্তে লগিং কোডে বাগটি ঠিক করবেন না কেন?

— ভিক্টর হুরডুগাচি

3

ভিক্টর, এটি সম্ভবত কোনও বাগ নয়। লগটি যদি ডিস্কে বাস করে তবে স্থানটি শেষ হয়ে যায়, এটি কি লগিং কোডের একটি বাগ?

— কারসন 63000

4

@ কারসন 63000 - ভাল, হ্যাঁ লগগুলি লেখা হচ্ছে না, তাই: বাগ। স্থির আকারের ঘোরানো লগগুলি কার্যকর করুন।

— অবধি

5

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

— রিওয়ালক

15

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

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

1

আমি তাত্ত্বিকভাবে এর সাথে একমত কিন্তু উপরে আমার লগিং উদাহরণ সম্পর্কে কি? আপনি যদি লগিং ব্যতিক্রমগুলি উপেক্ষা করে অবিরত রাখতে চান তবে কী হবে? আরও গুরুতর ব্যতিক্রমকে বুদ্বুদ আপ দেওয়ার সময় আপনার যে সমস্ত ব্যতিক্রম ছোঁড়া যায় এবং যেগুলি হ্যান্ডেল করা যায় সেগুলি ধরতে হবে?

— বব হর্ন

6

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

— sensক্যমত্য

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

— বব হর্ন

@ বিজনী আপনার লগিং উদাহরণটি বরং সংজ্ঞায়িত - বেশিরভাগ লগিং ফ্রেমওয়ার্ক যা আমি জানি, কোনও ব্যাতিক্রম ছুঁড়ে না ফেলে তার দৈর্ঘ্যের দিকে যান এবং সেভাবে আহ্বান করা হবে না (যেমন এটি কোনও "লগ স্টেটমেন্ট ওয়াই ফাইলের লাইন এক্সে ঘটেছে" অকেজো তৈরি করবে) )

@ পিডিআর আমি লগব্যাক তালিকার (জাভা) এ প্রশ্ন উত্থাপন করেছি যে লগিং কনফিগারেশন ব্যর্থ হলে লগিং কাঠামোটি কীভাবে অ্যাপ্লিকেশনটি থামিয়ে দিতে হয়, কেবলমাত্র এটি কারণ যে আমাদের লগগুলি খুব গুরুত্বপূর্ণ এবং কোনও নীরব ব্যর্থতা অগ্রহণযোগ্য। একটি ভাল সমাধান এখনও মুলতুবি আছে।

9

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

— রায়ান হেইস
সূত্র

5

দুটি সম্ভাবনা পারস্পরিক একচেটিয়া নয়।

একটি আদর্শ পরিস্থিতিতে, আপনি আপনার পদ্ধতিটি তৈরি করতে পারে এমন সমস্ত সম্ভাব্য প্রকারের ব্যয় ধরতে পারবেন, প্রতি-ব্যতিক্রম ভিত্তিতে এগুলি পরিচালনা করবেন এবং শেষ পর্যন্ত catchকোনও ভবিষ্যত বা অজানা ব্যতিক্রমগুলি ধরার জন্য একটি সাধারণ ধারা যুক্ত করুন । আপনি উভয় বিশ্বের সেরা পেতে এই উপায়।

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

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

সম্পাদনা করুন: মন্তব্যগুলিতে বর্ণিত কারণে, শেষ ক্যাচে একটি পুনর্বিবেচনা যুক্ত করেছে।

— Rotem
সূত্র

2

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

— পিডিআর

1

@ পিডিআর নিশ্চয়ই আপনি বুঝতে পেরেছেন এটি একটি স্বীকৃত উদাহরণ। মূল বক্তব্যটি হ'ল কীভাবে তা পরিচালনা করা নয়, নির্দিষ্ট এবং সাধারণ ব্যতিক্রম উভয়কেই ধরা দেয়।

— রোটেম

@ রোটেম আমি মনে করি আপনার এখানে একটি ভাল উত্তর আছে। কিন্তু পিডিআর একটি পয়েন্ট আছে। কোডটি যেমনটি ধরা পড়ে এবং চালিয়ে যায় ঠিক তেমন করে তোলে। কিছু শিক্ষানবিস, উদাহরণটি দেখে মনে হতে পারে যে এটি একটি ভাল পদ্ধতির।

— বব হর্ন

সহযোগিতা করেছে বা না, এটি আপনার উত্তরকে ভুল করে। আউট অফ মেমোরি এবং ডিস্ক ফুলের মতো ব্যতিক্রমগুলি ধরা এবং কেবল সেগুলি গ্রাস করতে শুরু করার সাথে সাথেই আপনি প্রমাণ করছেন যে সাধারণ ব্যতিক্রমগুলি ধরা আসলে কী খারাপ is

— পিডিআর

1

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

— ভিক্টর হুরডুগাচি

5

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

উদাহরণস্বরূপ নিন, অকুল ArgumentNullExceptionযা পারে একটি ব্যতিক্রম আপনার জন্য একটি যুক্তিসংগত প্রার্থী হতে না ধরতে চান, কারণ এটি tends কোড বদলে একটি বৈধ রানটাইম ভুলবশত একটি বাগ ইঙ্গিত। অই হ্যাঁ. সুতরাং করে NullReferenceException, যে ছাড়া NullReferenceExceptionথেকে আহরণ করা নেই SystemExceptionসরাসরি, তাই কোন বালতি আপনি সব "লজিক্যাল ত্রুটিগুলি" স্থাপন করতে পারেন মধ্যে ধরা (অথবা ধরা নয়) আছে।

তারপরে আইএমএনএসএইচও-র প্রধান বটচ রয়েছে যার SEHExceptionমাধ্যমে (মাধ্যমে ExternalException) প্রাপ্তি SystemExceptionএবং এটি এটিকে একটি "নরমাল" করে তুলবেSystemException যখন আপনি একটি পেয়ে যানSEHException, আপনি একটি ডাম্প লিখে যত তাড়াতাড়ি শেষ করতে চান - এবং নেট 4 দিয়ে শুরু করে কমপক্ষে কিছু এসইএইচ ব্যতিক্রমকে দুর্নীতিগ্রস্থ রাজ্য ব্যতিক্রম হিসাবে বিবেচনাকরা হয় যা ধরা পড়বে না। একটি ভাল জিনিস এবং একটি সত্য যাCA1031নিয়মটিকে আরও অকেজো করেতোলে, কারণ এখন আপনার অলসভাবেcatch (Exception)যাইহোক এইখারাপতম ধরণগুলিধরবে না।

তারপর, মনে হচ্ছে যে অন্যান্য ফ্রেমওয়ার্ক কাপড় বরং inconsistently পারেন আহরিত Exceptionসরাসরি বা মাধ্যমে SystemException, তীব্রতা তর্ক করা ভালো কিছু দ্বারা ক্যাচ-ক্লজ গোষ্ঠীবদ্ধ যে কোনো প্রচেষ্টা।

মিঃ লিপার্টের C#খ্যাতিমানের একটি টুকরো রয়েছে , যাকে ভেক্সিং এক্সেপশন বলা হয় , যেখানে তিনি ব্যতিক্রমগুলির কিছু কার্যকর শ্রেণীবদ্ধকরণ তুলে ধরেছেন : আপনি কেবল "বহিরাগত" পেতে চাইবেন এমন যুক্তি দিতে পারেন ... C#ভাষা এবং ডিজাইনের নকশা বাদে N কাঠামোর ব্যতিক্রমগুলি কোনও সংগত পদ্ধতিতে "কেবলমাত্র বহিরাগতদের ধরা" অসম্ভব করে তোলে। _{(এবং, যেমন, একটি OutOfMemoryExceptionহতে পারে খুব ভাল একটি API জন্য একটি সম্পূর্ণ স্বাভাবিক আদায়যোগ্য ত্রুটি বাফার যে একরকম বড় বরাদ্দ করা হয়েছে যে হতে)}

আমার জন্য বটম লাইন যে, পথ C#ধরা ব্লক কাজ এবং পথ ফ্রেমওয়ার্ক ব্যতিক্রম অনুক্রমের ডিজাইন করা হয়েছে, নিয়ম CA1031সম্পূর্ণভাবে অকেজো পরলোক হল । এটা তোলে ভান এর "ব্যতিক্রম গেলা না" কিন্তু ব্যতিক্রম গিলতে শূন্য কি আপনি ধরতে কি আছে, কিন্তু কি আপনার সাথে রুট সমস্যার সাথে সাহায্য করার জন্য তারপর একটি করুন:

আছে অন্তত 4 উপায়ে বৈধভাবে একটি ধরা হ্যান্ডেল করতে Exception, এবং CA1031শুধুমাত্র কৃত্রিম তাদের মধ্যে একজন (যথা পুনরায় থ্রো ক্ষেত্রে) হ্যান্ডেল বলে মনে হয়।

একটি সাইড নোট হিসাবে, একটি সি # 6 বৈশিষ্ট্য নামক ব্যতিক্রম ফিল্টার যে করতে হবে CA1031তারপর থেকে আবার সামান্য বেশি বৈধ আপনি সঠিকভাবে, সঠিকভাবে, সঠিকভাবে ব্যতিক্রম আপনি ধরতে চান ফিল্টার করতে সক্ষম হবে, এবং সেখানে কম কারণ একটি অপরিশুদ্ধ লিখতে এর catch (Exception)।

— মার্টিন বা
সূত্র

1

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

— সুপারক্যাট

1

@ সুপের্যাট - যথেষ্ট সত্য, তবে অন্য যে কোনও সাধারণ সিস্টেম ব্যতিক্রমের ক্ষেত্রে এটি বেশ সত্য, যখন কোনও অবশেষে ব্লকের জিনিস খারাপ হয়ে যায়।

— মার্টিন বা

1

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

— সুপারক্যাট

4

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

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

কটাক্ষপাত আছে এই যাতে আরও বেশি পড়ার জন্য উত্তর দিন।

— টম স্কোয়ায়ার্স
সূত্র

1

আপনি নিজে একটি সম্পূর্ণ সফ্টওয়্যার তৈরি করার সময় এই পরিস্থিতিটি (যখন কোনও বিকাশকারীকে অবশ্যই পোকেমন ট্রেনার হতে হবে) উপস্থিত হয়: আপনি স্তরগুলি, ডাটাবেস সংযোগগুলি এবং ব্যবহারকারীর জিইআই তৈরি করেছেন। আপনার অ্যাপ্লিকেশনটিকে অবশ্যই কানেক্টিভিটি নষ্ট হওয়া, ব্যবহারকারীর ফোল্ডার মোছা, ডেটা দূষিত হওয়া ইত্যাদি পরিস্থিতি থেকে পুনরুদ্ধার করতে হবে End তারা এমন অ্যাপ্লিকেশন পছন্দ করে যা জ্বলন্ত বিস্ফোরিত ক্র্যাশিং কম্পিউটারে কাজ করতে পারে!

— ব্রোকেন_উইন্ডো

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

— ম্যাগাস

2

@ ম্যাগাস: এই জাতীয় পদ্ধতির সাহায্যে LoadDocument()ভুল হতে পারে এমন সমস্ত বিষয় চিহ্নিত করা মূলত অসম্ভব, তবে নিক্ষেপযোগ্য 99% ব্যতিক্রমগুলির অর্থ সহজেই বোঝানো হবে "প্রদত্ত নামের সাথে কোনও ফাইলের বিষয়বস্তু ব্যাখ্যা করা সম্ভব হয়নি" একটি নথি; যদি কেউ এমন কোনও কিছু খোলার চেষ্টা করে যা বৈধ নথি ফাইল নয়, তবে অ্যাপ্লিকেশনটি ক্র্যাশ করা উচিত নয় এবং অন্য কোনও উন্মুক্ত দলিলকে মেরে ফেলা উচিত নয়। এই জাতীয় ক্ষেত্রে পোকেমন ত্রুটি পরিচালনা করা কুৎসিত, তবে আমি কোনও ভাল বিকল্প জানি না।

— সুপারক্যাট

@ সুপের্যাট: আমি কেবল একটি ভাষাগত বক্তব্য রাখছিলাম। তবে আমি মনে করি না যে অবৈধ ফাইলের সামগ্রীগুলি এমন এক জাতীয় শব্দ যা একাধিক ধরণের ব্যতিক্রম ছোঁড়া উচিত throw

— ম্যাগাস

1

@ ম্যাগাস: এটি সব ধরণের ব্যতিক্রম ছুঁড়ে ফেলতে পারে - এটাই সমস্যা। কোনও ফাইলে অবৈধ ডেটার ফলস্বরূপ যে সকল ধরণের ব্যতিক্রম হতে পারে তা প্রত্যাশা করা প্রায়শই খুব কঠিন। যদি কেউ পোকেমন হ্যান্ডলিং ব্যবহার না করে তবে একটি অ্যাপ্লিকেশন মারা যাওয়ার ঝুঁকি রয়েছে কারণ যেমন ফাইলটি লোড হচ্ছে এমন একটি জায়গায় একটি ব্যতিক্রমী-দীর্ঘ সংখ্যার স্ট্রিং রয়েছে যার দশমিক-বিন্যাসিত 32-বিট পূর্ণসংখ্যার প্রয়োজন হয় এবং একটি সংখ্যার ওভারফ্লো ঘটেছিল বিশ্লেষণ যুক্তি।

— সুপারক্যাট

1

সাধারণ ব্যতিক্রম ধরা খুব খারাপ কারণ এটি আপনার প্রোগ্রামটিকে একটি অনির্ধারিত অবস্থায় ফেলে দেয়। স্টাফগুলি কোথায় ভুল হয়েছে তা আপনি জানেন না যাতে আপনার প্রোগ্রামটি আসলে কী করেছে বা কী করেছে তা আপনি জানেন না।

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

বিতরণ করা পরিবেশে আপনার লগ পদ্ধতি ব্যাকফায়ার হতে পারে: একটি সাধারণ ব্যতিক্রম ধরা অর্থাত্ আপনার প্রোগ্রামটি এখনও লগ-ফাইলটিতে একটি লক ধরে রাখতে পারে যা অন্য ব্যবহারকারীদের লগ তৈরি করতে বাধা দেয়।

— পিটার বি
সূত্র

0

আমি এই নিয়মের যুক্তিটি বুঝতে পারি। তবে, বাস্তবে, যদি আমি নিক্ষিপ্ত ব্যতিক্রম নির্বিশেষে একই পদক্ষেপ নিতে চাই, তবে আমি কেন প্রত্যেককে বিশেষভাবে পরিচালনা করব?

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

তদুপরি, যদি আমি নির্দিষ্ট ব্যতিক্রমগুলি পরিচালনা করি তবে কী কোডটি আমি কল করছি যা ভবিষ্যতে নতুন ব্যতিক্রম ছড়িয়ে দেওয়ার জন্য কল করছি? নতুন ব্যতিক্রমটি পরিচালনা করতে এখন আমার কোডটি পরিবর্তন করতে হবে। আমি যদি কেবল ব্যতিক্রম ধরা পড়ে তবে আমার কোড পরিবর্তন করতে হবে না।

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

উদাহরণস্বরূপ, যদি ফু বার বার কল করে এবং ফু দ্বারা বার দ্বারা নিক্ষেপ করা ব্যতিক্রমের প্রকারটি নির্বিশেষে প্রক্রিয়াজাতকরণ বন্ধ করা দরকার, তবে আমি যে ধরণের ব্যতিক্রম ধরছি সে সম্পর্কে সুনির্দিষ্ট হওয়ার কোনও সুবিধা আছে কি?

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

তাহলে আমি যদি প্রতিটি ব্যতিক্রমকে আউটঅফ-মেমরিএক্সসেপশন উপেক্ষা করতে চাই তবে কী হবে?

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

— জন
সূত্র

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

— supercat

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

— সুপারক্যাট

0

হতে পারে । প্রতিটি নিয়মের ব্যতিক্রম রয়েছে এবং কোনও নিয়মই অবৈধভাবে অনুসরণ করা উচিত নয়। আপনি উদাহরণস্বরূপ এমন উদাহরণগুলির মধ্যে একটি হতে পারেন যেখানে সমস্ত ব্যতিক্রমগুলি গ্রাস করার জন্য এটি বোধগম্য। উদাহরণস্বরূপ, যদি আপনি একটি সমালোচনামূলক উত্পাদন সিস্টেমে ট্রেসিং যুক্ত করতে চান, এবং আপনি একেবারে নিশ্চিত করতে চান যে আপনি পরিবর্তনগুলি অ্যাপের মূল কাজটি ব্যাহত করবেন না don't

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

লগিং পদ্ধতিতে একটি প্রোগ্রামিং ত্রুটি যার কারণে এটি সর্বদা একটি নির্দিষ্ট ব্যতিক্রম ছোঁড়ে
কনফিগারেশনে লগিং ফাইলের একটি অবৈধ পথ
ডিস্কটি পূর্ণ

আপনি কি এই তাত্ক্ষণিক তাত্ক্ষণিক অবহিত হতে চান না যে এই সমস্যাটি রয়েছে, তাই আপনি এটি ঠিক করতে পারেন? ব্যতিক্রম গিলে ফেলার অর্থ আপনি কখনই জানেন না যে কিছু ভুল হয়েছে।

কিছু সমস্যা (যেমন ডিস্ক পূর্ণ রয়েছে) অ্যাপ্লিকেশনটির অন্যান্য অংশগুলিও ব্যর্থ হতে পারে - তবে এই ব্যর্থতাটি এখন লগ হয় নি, তাই আপনি কখনই জানেন না!

— JacquesB
সূত্র

0

আমি এটি প্রযুক্তিগতের চেয়ে যৌক্তিক দৃষ্টিকোণ থেকে সম্বোধন করতে চাই,

নতুন ব্যতিক্রমটি পরিচালনা করতে এখন আমার কোডটি পরিবর্তন করতে হবে।

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

আপনার প্রশ্নটি মূলত "যদি আমি কী ভুল হয়েছে সেদিকে খেয়াল না রাখি তবে কী ছিল? আসলে কী ছিল তা খুঁজে বের করতে আমাকে কি ঝামেলা করে যেতে হবে?"

এখানে সৌন্দর্যের অংশ: না আপনি করবেন না।

"সুতরাং, আমি কি অন্যভাবে দেখতে পারি এবং যা কিছু গন্ধযুক্ত জিনিস পপ আপ করে দেয় তা স্বয়ংক্রিয়ভাবে কার্পেটের নীচে ছড়িয়ে দেওয়া এবং এটি দিয়ে সম্পন্ন করা যায়?"

না, এটি হয় কিভাবে এটি কাজ করে না।

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

"তবে ... তবে ... তারপরেও আমি যে অন্যান্য ব্যতিক্রমগুলি যত্ন করি না তার মধ্যে একটির কারণে আমার কাজটি ব্যর্থ হতে পারে!"

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

— মার্টিন মাট
সূত্র

-3

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

আপনার সাধারণ ব্যতিক্রমগুলি ধরা এবং কার্যকর করা চালিয়ে যাওয়ার চেষ্টা করা উচিত নয়।

— ddyer
সূত্র