জন্য যদি অ্যান্টিপ্যাটার্ন


9

আমি এই ব্লগ পোস্টে অ্যান্টি-প্যাটার্ন-বিরোধী প্যাটার্ন সম্পর্কে পড়ছিলাম এবং আমি কেন এটি একটি বিরোধী-প্যাটার্ন কারণ তা আমি নিশ্চিতভাবে নিশ্চিত নই।

foreach (string filename in Directory.GetFiles("."))
{
    if (filename.Equals("desktop.ini", StringComparison.OrdinalIgnoreCase))
    {
        return new StreamReader(filename);
    }
}

প্রশ্ন 1:

এটা return new StreamReader(filename);ভিতরে কারণ for loop? বা forএই ক্ষেত্রে আপনার কোনও লুপের দরকার নেই তা এই সত্য ?

ব্লগের লেখক হিসাবে এর কম উন্মাদ সংস্করণটি নির্দেশ করেছেন:

if (File.Exists("desktop.ini"))
{
    return new StreamReader("desktop.ini");
} 

উভয়ই একটি বর্ণের শর্তে ভুগছেন কারণ ফাইলটি তৈরির আগে মুছে ফেলা হলে StreamReaderআপনি একটি পাবেন File­Not­Found­Exception

প্রশ্ন 2:

দ্বিতীয় উদাহরণটি ঠিক করার জন্য, আপনি যদি বিবৃতিটি না দিয়ে এটিকে আবার লিখবেন, এবং পরিবর্তে StreamReaderএকটি চেষ্টা-ধরার ব্লক দিয়ে ঘিরে ফেলুন, এবং যদি এটি একটি ছুড়ে ফেলে File­Not­Found­Exceptionআপনি catchসেই অনুসারে ব্লকটি পরিচালনা করেন?



1
@ আমন - ধন্যবাদ, তবে আমি কোনও অতিরিক্ত পয়েন্ট দিচ্ছি না, আমি নিবন্ধটি কী বলছে এবং আমি কীভাবে এটি সংশোধন করব তা বোঝার চেষ্টা করছি।

3
আমি এতো ভাবনা দিতাম না। ব্লগ পোস্টারটি এমন কিছু বুদ্ধিমান কোড তৈরি করছে যা কেউ লিখে না, নাম দেয় এবং এটিকে একটি অ্যান্টি-প্যাটার্ন বলে। এখানে আরেকটি রয়েছে: "আমি একে অর্থহীন অ্যাসাইনমেন্ট প্যাটার্ন বলি: x = x; আমি দেখি এটি সব সময় করা হচ্ছে So তাই বোকা I আমি মনে করি আমি এটি সম্পর্কে একটি ব্লগ লিখব" "
মার্টিন মাট 18'18

4
To fix the second example, would you re-write it without the if statement, and instead surround the StreamReader with a try-catch block, and if it throws a File­Not­Found­Exception you handle it in the catch block accordingly?- হ্যাঁ, আমি ঠিক তাই করতাম। "নিয়ন্ত্রণ প্রবাহ হিসাবে ব্যতিক্রম" এর কিছু ধারণার চেয়ে দৌড়ের অবস্থার সমাধান করা আরও গুরুত্বপূর্ণ এবং এটি এটিকে মার্জিত এবং পরিষ্কারভাবে সমাধান করে।
রবার্ট হার্ভে

1
যদি ফাইলগুলি উভয়ই প্রদত্ত মানদণ্ড না মেনে চলে তবে তা কী করবে? এটি কি ফিরে আসে null? আপনার কোডটি কোডের মতো দেখতে কোডটি পরিষ্কার করার জন্য আপনি সাধারণত লিনকিউ ব্যবহার করতে পারেন: দুটি লিনকিউ কলের মধ্যে অপারেটরটি return Directory.GetFiles(".").FirstOrDefault(fileName => fileName.Equals("desktop.ini", StringComparison.OrdinalIgnoreCase))?.Select(fileName => new StreamReader(filename)); লক্ষ্য করুন ?.। এছাড়াও লোকেরা তর্ক করতে পারে যে এর মতো অবজেক্ট তৈরি করা লিনকিউ-এর সবচেয়ে উপযুক্ত ব্যবহার নয়, তবে আমি মনে করি এটি এখানে ঠিক আছে। এটি আপনার প্রশ্নের উত্তর নয়, তবে এটির একটি অংশে খনন করে।
Panzercrisis

উত্তর:


7

এটি এন্টিপ্যাটার্ন হিসাবে এটি রূপ নেয়:

loop over a set of values
   if current value meets a condition
       do something with value
   end
end

এবং সঙ্গে প্রতিস্থাপন করা যেতে পারে

do something with value

এর একটি ক্লাসিক উদাহরণ কোডের মতো:

for (var i=0; i < 5; i++)
{
    switch (i)
        case 1:
            doSomethingWith(1);
            break;
        case 2:
            doSomethingWith(2);
            break;
        case 3:
            doSomethingWith(4);
            break;
        case 4:
            doSomethingWith(4);
            break;
    }
}

যখন নিম্নলিখিতটি ঠিক কাজ করে:

doSomethingWith(1);
doSomethingWith(2);
doSomethingWith(3);
doSomethingWith(4);

আপনি নিজেকে একটি লুপ করণ এবং একটি যদি জানতে ifবা switch, তারপর বন্ধ করা এবং আপনি কি করছেন আমার মনে হয়। আপনি কি জিনিসগুলিকে অতি জটিল করে তুলছেন এবং পুরো লুপ এবং পরীক্ষাটি কেবল একটি "সাধারণভাবে এটি" লাইনের সাথে প্রতিস্থাপন করা যেতে পারে? কখনও কখনও যদিও, আপনি দেখতে পাবেন যে লুপটি করতে হবে (উদাহরণস্বরূপ একাধিক আইটেমের একটি শর্তের সাথে মেলে), এই ক্ষেত্রে প্যাটার্নটি ভাল is

এ কারণেই এটি একটি বিরোধী-নিদর্শন: এটি "লুপ এবং পরীক্ষা" প্যাটার্নটি নেয় এবং এটিকে গালি দেয়।

আপনার দ্বিতীয় প্রশ্ন সম্পর্কে: হ্যাঁ। আপনার কোড পুরো ডিভাইসে একমাত্র থ্রেড নয় যা পরীক্ষার অধীনে আইটেমের অবস্থার পরিবর্তন করতে পারে এমন কোনও পরিস্থিতিতে "টেস্ট ডু" প্যাটার্নটি "টেস্ট টু ডু" প্যাটার্নের চেয়েও শক্ত।

এই কোডটি নিয়ে সমস্যা:

if (File.Exists("desktop.ini"))
{
    return new StreamReader("desktop.ini");
}

সেই সময়টি File.Existsএবং StreamReaderসেই ফাইলটি খোলার চেষ্টা করার মধ্যবর্তী সময়ে , অন্য থ্রেড বা প্রক্রিয়া ফাইলটি মুছতে পারে। সুতরাং আপনি একটি ব্যতিক্রম পাবেন। অতএব যে ব্যতিক্রম কিছু থেকে রক্ষা করা প্রয়োজন:

try
{
    return new StreamReader("desktop.ini");
}
catch (File­Not­Found­Exception)
{
    return null; // or whatever
}

@ ফ্লাটার একটি ভাল পয়েন্ট উত্থাপন? এটি কি নিজেই একটি প্রতিষেধক? আমরা কি নিয়ন্ত্রণ প্রবাহ হিসাবে ব্যতিক্রম ব্যবহার করছি?

কোড যদি কিছু পড়তে থাকে:

try
{
    if (!File.Exists("desktop.ini")
    {
        throw new IniFileMissingException();
        return new StreamReader("desktop.ini");
    }
}
catch (IniFileMissingException)
{
    return null;
}

তাহলে আমি অবশ্যই ব্যতিক্রমগুলি গৌরবময় গোটো হিসাবে ব্যবহার করব এবং এটি অবশ্যই একটি বিরোধী-নিদর্শন হবে। তবে এক্ষেত্রে আমরা কেবল একটি নতুন স্ট্রিম তৈরির অনাকাঙ্ক্ষিত আচরণের আশেপাশে কাজ করছি, সুতরাং এটি সেই অ্যান্টি-প্যাটার্নের উদাহরণ নয়। তবে এটি সেই অ্যান্টি-প্যাটার্নকে ঘিরে কাজ করার একটি উদাহরণ।

অবশ্যই, আমরা যা চাই তা হ'ল স্ট্রিমটি তৈরি করার আরও মার্জিত উপায় way কিছুটা এইরকম:

return TryCreateStream("desktop.ini", out var stream) ? stream : null;

এবং আমি try catchযদি এই কোডটি কোনও ইউটিলিটি পদ্ধতিতে মোড়ানোর পরামর্শ দিই যদি আপনি নিজেকে এই কোডটি অনেক বেশি ব্যবহার করে দেখেন।


1
@ ফ্লাটার, আমি একমত যে এটি আদর্শ নয় (যদিও আমি বিতর্ক করি যে এটি বিরোধী প্যাটার্নের একটি উদাহরণ যা এর উত্তর দেয়)। কোডটির উদ্দেশ্যটি নয়, যান্ত্রিকগুলি নয়। তাই আমি Scala এর ভালো কিছু পক্ষপাতী চাই Try, যেমন return Try(() => new StreamReader("desktop.ini")).OrElse(null);, কিন্তু C # এর যে কনস্ট্রাক্ট অবলম্বন পাওয়া যায়নি (ক 3rd পার্টি লাইব্রেরি ব্যবহার না করেই), তাই আমরা ক্লাঙ্কি সংস্করণের সাথে কাজ করতে হবে।
ডেভিড আরনো

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

1
@ ফ্লাটার: দ্বিতীয় কোডের নমুনাটি ফাইলটি খোলার সঠিক উপায় way অন্য যে কোনও কিছু একটি জাতির শর্ত প্রবর্তন করে। এমনকি যদি আপনি সেই ফাইলের অস্তিত্ব পরীক্ষা করে থাকেন এবং সেই চেকটির মধ্যে এবং যখন আপনি প্রকৃতপক্ষে এটি খোলেন তখন কিছু আপনার কাছে সেই ফাইলটি উপলভ্য নয় এবং ওপেন () কলটি বিস্ফোরিত হবে। সুতরাং আপনাকে যেভাবেই হোক ব্যতিক্রমের জন্য প্রস্তুত থাকতে হবে। সুতরাং আপনি পাশাপাশি পরীক্ষা করতে বিরক্ত করবেন না এবং চেষ্টা করুন এবং এটি খুলুন। ব্যতিক্রমগুলি হ'ল সরঞ্জামগুলি যা আমাদের জিনিসগুলি সম্পন্ন করতে সহায়তা করে এবং সেগুলির ব্যবহারকে ধর্মীয় মতবাদ হিসাবে দেখা উচিত নয়।
18:58

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

1
@ ফ্লাটার " আপনি কার্যকরভাবে যুক্তি দিচ্ছেন যে প্রতিটি পদ্ধতির কলটির একটি রিটার্ন টাইপ দরকার ... যা কার্যকরভাবে আলাদাভাবে ব্যতিক্রমগুলি পুনরুদ্ধার করার চেষ্টা করছে "। সঠিক। যদিও সেই পুনর্বিবেচনা আমার নয়। এটি কয়েক বছর ধরে কার্যকরী ভাষায় ব্যবহৃত হচ্ছে। তারা সাধারণত পুরো "নিয়ন্ত্রণ প্রবাহের সমস্যা হিসাবে ব্যতিক্রমগুলি" এড়িয়ে চলে (যা আপনি বিভ্রান্তিমূলকভাবে দাবি করেন যে একটি শ্বাসে একটি বিরোধী ধাঁচ এবং তারপরে পরবর্তী পক্ষের পক্ষে যুক্তিযুক্ত) ইউনিয়ন প্রকারগুলি ব্যবহার করে, যেমন এই ক্ষেত্রে আমরা কোনও Maybe<Stream>প্রকার ব্যবহার করতাম nothingফাইলটি উপস্থিত না থাকলে এবং যদি না থাকে তবে একটি স্ট্রিম ফিরে আসে returns
ডেভিড আরনো

1

প্রশ্ন 1: (এটি কি একটি অ্যান্টিপ্যাটার্ন-লুপ)

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

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

আসুন একটি মুহুর্তের জন্য ভান করুন যে আপনি কোনও ফাইল সিস্টেমের ডিরেক্টরিতে ডিরেক্টরিতে একটি ফাইলের পরিবর্তে একটি ডাটাবেসে রেকর্ড খুঁজছেন। আপনি বরং দেখতে চান

SELECT * FROM SomeTable;

এবং তারপরে লুপে (উদাহরণস্বরূপ সি # তে) ফিরে আসা কার্সার থেকে আইডি = 100 অনুসন্ধান করা, বা অনুসন্ধানযোগ্য সাবসিস্টেমটি এটির পরিবর্তে আপনি যা খুঁজছেন তা ঠিক কী খুঁজে পেতে পারে?

SELECT * FROM SomeTable WHERE ID = 100;

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


প্রশ্ন 2: দ্বিতীয় উদাহরণটি ঠিক করার জন্য, আপনি কি এই বিবৃতিটি না দিয়ে এটিকে আবার লিখবেন এবং পরিবর্তে স্ট্রিমরেডারকে একটি ট্রাই-ক্যাচ ব্লক দিয়ে ঘিরে ফেলবেন এবং যদি কোনও ফাইলনটফাউন্ডএক্সেপশন নিক্ষেপ করে আপনি সেই অনুসারে ক্যাচ ব্লকে হ্যান্ডেল করেন?

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


0

প্রশ্ন 1:

এটি কি নতুন স্ট্রিমরিডার (ফাইলের নাম) ফেরতের কারণে; লুপ জন্য ভিতরে? বা এই ক্ষেত্রে আপনার কোনও লুপের দরকার নেই তা এই সত্য?

এর সাথে স্ট্রিমডারারের কোনও সম্পর্ক নেই। অ্যান্টি-প্যাটার্নটি উত্থাপিত হয় কারণ foreachএবং এর মধ্যে অভিপ্রায়গুলির স্পষ্ট দ্বন্দ্বের কারণে if:

এর উদ্দেশ্য কী foreach?

আমি ধরে নিলাম আপনার উত্তরটি এমন কিছু হবে: "আমি বারবার একটি নির্দিষ্ট কোডের টুকরোগুলি কার্যকর করতে চাই "

আপনি কতগুলি ফাইল প্রক্রিয়া করার প্রত্যাশা করছেন?

যেহেতু আপনার নির্দিষ্ট ফোল্ডারে কেবলমাত্র একটি নির্দিষ্ট ফাইলের নাম থাকতে পারে (এক্সটেনশন সহ), এটি প্রমাণ করে যে আপনার কোডটি একটি কার্যকর ফাইল খুঁজে পেতে পারে ।

আপনি অবিলম্বে কোনও মান ফিরিয়ে দিচ্ছেন তা দ্বারা এটিও নিশ্চিত হয়ে যায়। আপনি আসলে দ্বিতীয় ম্যাচটি সম্পর্কে চিন্তা করেন না, এমনকি এটি উপস্থিত থাকলেও।


এমন পরিস্থিতি রয়েছে যেখানে এটি কোনও বিরোধী-নিদর্শন নয়।

  • আপনি যদি উপ-ডিরেক্টরিগুলিতে ( Directory.GetFiles(".", SearchOption.AllDirectories)) ও সন্ধান করেন তবে একই ফাইল নাম (এক্সটেনশন সহ) সহ একাধিক ফাইল সন্ধান করা সম্ভব
  • আপনি যদি আংশিক ফাইলের সাথে মিল খুঁজে পান (যেমন প্রতিটি ফাইল যার নাম দিয়ে শুরু হয় "Test_", বা প্রতিটি "*.zip"ফাইল)।

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


প্রশ্ন 2:

দ্বিতীয় উদাহরণটি ঠিক করার জন্য, আপনি কি এই বিবৃতিটি না দিয়ে এটিকে আবার লিখবেন এবং পরিবর্তে স্ট্রিমরেডারকে একটি ট্রাই-ক্যাচ ব্লক দিয়ে ঘিরে রাখবেন এবং যদি এটি ফাইলনটফাউন্ডএক্সেপশন নিক্ষেপ করে আপনি সেই অনুসারে ক্যাচ ব্লকে হ্যান্ডেল করেন?

ব্যতিক্রম ব্যয়বহুল। এগুলি কখনই সঠিক প্রবাহ যুক্তির পরিবর্তে ব্যবহার করা উচিত নয়। ব্যতিক্রমগুলি হ'ল তাদের নাম ব্যতিক্রমী পরিস্থিতিতে পরামর্শ দেয় ।

যে কারণে, আপনি এটি অপসারণ করা উচিত নয় if

সফ্টওয়্যারইজাইনারিং.এসই-তে এই উত্তর অনুসারে :

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

কেন, সাধারণভাবে এটি একটি অ্যান্টি-প্যাটার্নের দ্রুত সংক্ষিপ্তসার হিসাবে:

  • ব্যতিক্রমগুলি হ'ল সংক্ষেপে পরিশীলিত GOTO বিবৃতি
  • ব্যতিক্রম সহ প্রোগ্রামিং, সুতরাং কোড পড়তে এবং বুঝতে আরও অসুবিধার দিকে নিয়ে যায়
  • বেশিরভাগ ভাষায় ব্যতিক্রমগুলি ব্যবহার না করেই আপনার সমস্যার সমাধানের জন্য ডিজাইন করা বিদ্যমান নিয়ন্ত্রণ কাঠামো রয়েছে
  • দক্ষতার জন্য যুক্তিগুলি আধুনিক সংকলকগুলির পক্ষে ঝোঁক হতে থাকে, যা নিয়ন্ত্রণ প্রবাহের জন্য ব্যতিক্রমগুলি ব্যবহৃত হয় না এমন ধারণার সাথে অনুকূল হয় to

আরও গভীরতর তথ্যের জন্য ওয়ার্ডের উইকিতে আলোচনাটি পড়ুন ।

আপনার যদি চেষ্টা / ক্যাপচারে এটি মোড়ানোর প্রয়োজন হয় তবে তা আপনার পরিস্থিতির উপর নির্ভর করে:

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

কিছুই সবসময় "সর্বদা এটি ব্যবহার করুন" এর বিষয় নয়। আমার বক্তব্য প্রমাণ করতে:

পৃথক অধ্যয়ন প্রমাণিত হয়েছে যে আপনি যখন কোনও সুরক্ষা হেলমেট, সুরক্ষা গগলস এবং বুলেটপ্রুফ ন্যস্ত রাখেন তখন আপনার আহত হওয়ার সম্ভাবনা কম।

তাহলে কেন আমরা সকলেই এই সুরক্ষা সরঞ্জামটি সর্বদা পরা করি না?

এর সহজ উত্তর হ'ল কারণ সেগুলি পরিধানের ক্ষেত্রে অসুবিধা রয়েছে:

  • এটির জন্য অর্থ ব্যয় হয়
  • এটি আপনার চলাচলকে আরও জটিল করে তোলে
  • এটি পরতে বেশ উষ্ণ হতে পারে।

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

  • নির্মাণকর্মীরা তাদের কাজের সময় কোনও আঘাতের শিকার হওয়ার সম্ভাবনা বেশি থাকে। সেফটি হেলমেট থেকে তারা উপকৃত হয়।
  • অন্যদিকে অফিসের কর্মীদের আহত হওয়ার সম্ভাবনা অনেক কম। সুরক্ষা হেলমেট এটি মূল্যবান নয়।
  • অফিসের কর্মীর তুলনায় সোয়াট দলের সদস্যের গুলি করার সম্ভাবনা অনেক বেশি।

আপনি কি চেষ্টা করে / ধরার জন্য কলটি আবৃত করবেন? এটির উপর নির্ভর করে যে এটি করার সুবিধাগুলি এটির বাস্তবায়নের ব্যয়কে ছাড়িয়ে যায় কিনা on

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

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

সুতরাং পছন্দ আপনার হয়। এটা করে লাভ আছে কি? আপনি কি মনে করেন যে এটি প্রয়োগের জন্য ব্যয় করার চেয়ে বেশি, অ্যাপ্লিকেশনটিকে উন্নত করে?

আপডেট - আমি একটি মন্তব্য থেকে অন্য উত্তরে লিখেছিলাম, কারণ আমি মনে করি এটি আপনার জন্যও প্রাসঙ্গিক বিবেচনা:

এটি খুব আশেপাশের প্রসঙ্গে h

  • যদি স্ট্রিমডিডারটি খোলার আগে হয় if(!File.Exists) File.Create()তবে স্ট্রিমরিডারটি খোলার সময় ফাইলটির অনুপস্থিতি অবশ্যই ব্যতিক্রমী
  • যদি বিদ্যমান ফাইলগুলির একটি তালিকা থেকে ফাইলের নামটি নির্বাচিত করা হয়, তবে এর হঠাৎ অনুপস্থিতি আবার ব্যতিক্রম
  • আপনি যদি এমন স্ট্রিং নিয়ে কাজ করছেন যা আপনি এখনও ডিরেক্টরিটির বিরুদ্ধে পরীক্ষা করেন নি; তারপরে ফাইলটির অনুপস্থিতি পুরোপুরি যৌক্তিক ফলাফল, এবং তাই ব্যতিক্রমী নয়
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.