কেন চেষ্টা করুন {…} অবশেষে {…} ভাল; {…} ধরা {} খারাপ চেষ্টা করুন?

201

আমি লোকদের বলতে দেখেছি যে বিনা যুক্তিতে ক্যাচ ব্যবহার করা খারাপ ফর্ম, বিশেষত যদি সেই ক্যাচটি কিছু না করে:

StreamReader reader=new  StreamReader("myfile.txt");
try
{
  int i = 5 / 0;
}
catch   // No args, so it will catch any exception
{}
reader.Close();

তবে এটি ভাল ফর্ম হিসাবে বিবেচিত হয়:

StreamReader reader=new  StreamReader("myfile.txt");
try
{
  int i = 5 / 0;
}
finally   // Will execute despite any exception
{
  reader.Close();
}

যতদূর আমি বলতে পারি, ক্লিনআপ কোডটি শেষ অবধি ব্লক করা এবং ট্রাই করার পরে ক্লিনআপ কোড স্থাপনের মধ্যে একমাত্র পার্থক্য। যদি আপনার চেষ্টা ব্লকে আপনার রিটার্নের স্টেটমেন্ট থাকে (তবে সেই ক্ষেত্রে ক্লিনআপ কোডটি শেষ পর্যন্ত হবে) চালান, কিন্তু চেষ্টা করার পরে কোড। সিচ হবে না)।

নাহলে, শেষ পর্যন্ত কী বিশেষ?

— mbeckish
সূত্র

7

আপনি যে বাঘটিকে পরিচালনা করতে পারবেন না ধরার চেষ্টা করার আগে আপনার শেষের ইচ্ছার দলিল করা উচিত।

ডকুমেন্টেশনে ব্যতিক্রম বিষয়গুলি কিছু ভাল অন্তর্দৃষ্টি দিতে পারে। এছাড়াও কটাক্ষপাত করা অবশেষে ব্লক উদাহরণ।

— এথফাউড

357

বড় পার্থক্যটি হ'ল try...catchব্যতিক্রমটি গিলে ফেলবে এবং ত্রুটি ঘটেছে তা লুকিয়ে রাখবে। try..finallyআপনার ক্লিনআপ কোডটি চালাবে এবং তারপরে ব্যতিক্রমটি চলতে থাকবে, এমন কিছু দ্বারা পরিচালিত হবে যা এর সাথে কী করতে পারে to

— Khoth
সূত্র

11

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

— ডেভিড আরনো

3

বেশিরভাগ ক্ষেত্রে, শ্রেণিবদ্ধ স্তরের স্তরের তুলনায় অ্যাপ্লিকেশন স্তর (যেমন, একটি নির্দিষ্ট কনফিগারেশন সেটিংস) থেকে কেন একটি নির্দিষ্ট ব্যতিক্রম ঘটবে তা আরও স্পষ্ট।

— মার্ক সিডেড

88

ডেভিড - আমি প্রোগ্রামটি দ্রুত ব্যর্থ হওয়ার পক্ষে অগ্রাধিকার দেব যাতে সমস্যা সম্পর্কে আমাকে সচেতন করা যায় বরং প্রোগ্রামটি অজানা অবস্থায় চলতে দেয়।

— এরিক ফোর্বস

6

যদি কোনও ব্যতিক্রমের পরে যদি আপনার প্রোগ্রামটি অজানা অবস্থায় থাকে তবে আপনি কোডটি ভুল করছেন।

— Zan Lynx

41

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

— ইহানেই

62

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

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

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

— অ্যাডাম রাইট
সূত্র

1

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

— সুপারক্যাট 20'13

32

কারণ যখন একটি একক লাইন একটি ব্যতিক্রম ছুঁড়ে ফেলেছে, আপনি এটি জানেন না।

কোডের প্রথম ব্লকের সাথে, ব্যতিক্রমটি সহজভাবে শোষিত হবে , প্রোগ্রামটির অবস্থাটি ভুল হতে পারে এমনকী প্রোগ্রামটি চালিয়ে যেতে থাকবে।

দ্বিতীয় ব্লক সহ, ব্যতিক্রম নিক্ষেপ করা হবে এবং বুদবুদ আপ হবে তবে এটি reader.Close()চালানোর গ্যারান্টিযুক্ত।

যদি কোনও ব্যতিক্রম প্রত্যাশিত না হয়, তবে চেষ্টা করে দেখুন না .c

— চাকরিট
সূত্র

21

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

এছাড়াও, নিম্নলিখিত নির্মাণগুলি ব্যবহার করার চেষ্টা করা আরও ভাল:

using (StreamReader reader=new  StreamReader("myfile.txt"))
{
}

যেহেতু ব্যবহারের বিবৃতিটি স্বয়ংক্রিয়ভাবে একটি চেষ্টায় আবদ্ধ হয় / অবশেষে এবং স্ট্রিমটি স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যাবে। (আপনি যদি সত্যিই ব্যতিক্রমটি ধরতে চান তবে আপনার ব্যবহারের বিবৃতিটি ঘিরে চেষ্টা করতে / ধরতে হবে)।

— ইঙ্গ্রাম চিহ্নিত করুন
সূত্র

5

এটি সঠিক নয়। ব্যবহার চেষ্টা করে / ধরা দিয়ে কোডটি

— মোড়ায় না,

8

নিম্নলিখিত 2 কোড ব্লক সমতুল্য হলেও তারা সমান নয়।

try
{
  int i = 1/0; 
}
catch
{
  reader.Close();
  throw;
}

try
{
  int i = 1/0;
}
finally
{
  reader.Close();
}

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

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

— রবার্ট পলসন
সূত্র

5

এখানে theক্যমত্য বলে মনে হচ্ছে এর সাথে আমি একমত - একটি খালি 'ক্যাচ' খারাপ, কারণ চেষ্টা ব্লকটিতে যা-কিছু ব্যতিক্রম ঘটেছে তা মুখোশ করে।

এছাড়াও, পাঠযোগ্যতার দৃষ্টিকোণ থেকে যখন আমি একটি 'চেষ্টা' ব্লক দেখি তখন আমি অনুমান করি যে এখানে একটি অনুরূপ 'ক্যাচ' বিবৃতি থাকবে। 'অবশেষে' ব্লকে রিসোর্সগুলি ডি-বরাদ্দ করা হয়েছে তা নিশ্চিত করার জন্য যদি আপনি কেবল 'চেষ্টা' ব্যবহার করেন তবে আপনি পরিবর্তে 'ব্যবহার' বিবৃতি বিবেচনা করতে পারেন :

using (StreamReader reader = new StreamReader('myfile.txt'))
{
    // do stuff here
} // reader.dispose() is called automatically

আপনি আইডিজিপোজেবল কার্যকর করে যে কোনও বস্তুর সাথে 'ব্যবহার করে' বিবৃতি ব্যবহার করতে পারেন। অবজেক্টের নিষ্পত্তি () পদ্ধতিটি ব্লকের শেষে স্বয়ংক্রিয়ভাবে কল হয়।

— ক্রিস লোলর
সূত্র

4

ব্যবহার করুন Try..Catch..Finally, যদি আপনার পদ্ধতিটি স্থানীয়ভাবে ব্যতিক্রমগুলি পরিচালনা করতে জানে knows ব্যতিক্রম ট্রাই, হ্যান্ডেল ইন ক্যাচে ঘটে এবং এর পরে ক্লিন আপ শেষ পর্যন্ত হয়।

যদি আপনার পদ্ধতিটি কীভাবে ব্যতিক্রমটি পরিচালনা করতে জানে না তবে ব্যবহারের পরে এটি পরিষ্কার করার দরকার পড়ে Try..Finally

এটির মাধ্যমে কলিং পদ্ধতিতে ব্যতিক্রম প্রচার করা হয় এবং কলিং পদ্ধতিগুলিতে কোনও উপযুক্ত ক্যাচের বিবৃতি উপস্থিত থাকলে পরিচালনা করা হয় f যদি বর্তমান পদ্ধতিতে বা কলিং পদ্ধতিগুলির মধ্যে কোনও ব্যতিক্রম হ্যান্ডলার না থাকে তবে অ্যাপ্লিকেশন ক্রাশ হয়।

Try..Finallyএটির মাধ্যমে এটি নিশ্চিত করা হয় যে কলিং পদ্ধতিগুলিতে ব্যতিক্রম প্রচারের আগে স্থানীয় পরিষ্কার করা সম্পন্ন হয়।

— manjuv
সূত্র

1

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

— জেসি উইলিয়ামস

3

চেষ্টা করুন..ফিনালি ব্লকটি এখনও উত্থাপিত কোনও ব্যতিক্রম ছুঁড়ে ফেলবে। সমস্ত finallyকিছুই নিশ্চিত করে যে ব্যতিক্রম ছোঁড়ার আগে ক্লিনআপ কোডটি চালানো হচ্ছে।

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

আর একটি কারণ হ'ল চেষ্টা করুন .c এটি করে আপনি যা বলছেন তা হ'ল "যাই ঘটুক না কেন, আমি এটি পরিচালনা করতে পারি।" কি StackOverflowExceptionহবে, তার পরে আপনি পরিষ্কার করতে পারেন? কি হবে OutOfMemoryException? সাধারণভাবে, আপনার কেবলমাত্র ব্যতিক্রমগুলি হ্যান্ডেল করা উচিত যা আপনি প্রত্যাশা করেন এবং কীভাবে পরিচালনা করবেন know

— OwenP
সূত্র

2

কোন ব্যতিক্রমটি কী ধরতে হবে বা কী করতে হবে তা যদি আপনি না জানেন তবে ক্যাচ স্টেটমেন্ট থাকার কোনও মানে নেই। আপনার কেবল এটি একটি উচ্চ-আপ কলারের জন্য ছেড়ে দেওয়া উচিত যা করার জন্য পরিস্থিতি সম্পর্কে আরও তথ্য থাকতে পারে।

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

— মার্ক সিডে
সূত্র

2

পাঠযোগ্যতার দৃষ্টিকোণ থেকে, এটি ভবিষ্যতের কোড-পাঠকদের আরও স্পষ্টভাবে বলছে "এখানে এই জিনিসগুলি গুরুত্বপূর্ণ, যা ঘটুক না কেন এটি করা দরকার" " এটা ভাল.

এছাড়াও, খালি ক্যাচ স্টেটমেন্টগুলিতে তাদের একটি নির্দিষ্ট "গন্ধ" থাকে। এগুলি একটি লক্ষণ হতে পারে যে বিকাশকারীরা ঘটতে পারে এমন বিভিন্ন ব্যতিক্রম এবং কীভাবে তাদের পরিচালনা করতে পারে তা নিয়ে চিন্তাভাবনা করছেন না।

— রায়ান
সূত্র

2

পরিশেষে alচ্ছিক - পরিষ্কার করার কোনও সংস্থান না থাকলে "শেষ অবধি" ব্লক করার কোনও কারণ নেই।

— গাই স্টারবাক
সূত্র

2

থেকে নেওয়া: এখানে

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

স্ট্রিম হিসাবে দিম স্ট্রিম = গেটস্ট্রিম () যদি (str.CanRead) তারপর 'স্ট্রিম পড়তে কোড যদি শেষ হয়

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

কোডিং কৌশলটি "ব্যতিক্রম হওয়া পর্যন্ত" চালিয়ে যাওয়ার পারফরম্যান্সের প্রভাবটি চিত্রিত করার জন্য, কোনও কাস্টের পারফরম্যান্স, যা কাস্ট ব্যর্থ হলে একটি অকার্যকস্টেক্সপশন নিক্ষেপ করে, সি # এর সাথে অপারেটর হিসাবে তুলনা করা হয়, যা যদি কাস্ট ব্যর্থ হয় তবে নাল ফেরায়। দুটি কৌশলটির পারফরম্যান্স একই ক্ষেত্রে যেখানে castালাই বৈধ আছে (টেস্ট ৮.০৫ দেখুন) তবে কাস্টটি অবৈধ রয়েছে এমন ক্ষেত্রে এবং একটি castালাই ব্যবহার ব্যতিক্রম ঘটায়, castালাই ব্যবহারের চেয়ে times০০ গুণ ধীর অপারেটর হিসাবে (পরীক্ষা 8.06 দেখুন)। ব্যতিক্রম-নিক্ষেপ প্রযুক্তির উচ্চ-কর্মক্ষমতা প্রভাবের মধ্যে বরাদ্দ, নিক্ষেপ, এবং ব্যতিক্রম ধরা এবং ব্যতিক্রমের অবজেক্টের পরবর্তী জঞ্জাল সংগ্রহের ব্যয় অন্তর্ভুক্ত থাকে, যার অর্থ ব্যতিক্রম ছোঁড়ার তাত্ক্ষণিক প্রভাব এই উচ্চ নয়। আরও ব্যতিক্রম নিক্ষেপ হিসাবে,

— SpoiledTechie.com
সূত্র

2

স্কট - উপরে বর্ণিত পাঠ্যটি বিশেষজ্ঞ এক্সচেঞ্জ.কমের পে-ওয়াল এর পিছনে থাকলে আপনার সম্ভবত এটি পোস্ট করা উচিত নয়। আমি এতে ভুল হতে পারি তবে আমি বাজি ধরব এটি কোনও ভাল ধারণা নয়।

— ওনোরিও ক্যাটেনাচি

2

কেবল ব্যতিক্রমটি পুনর্বিবেচনার জন্য ক্যাচ ক্লজ যুক্ত করা খারাপ অভ্যাস।

— বাসটিয়েন ভন্ডমমে
সূত্র

2

আপনি যদি প্রোগ্রামারদের জন্য সি # পড়েন তবে আপনি বুঝতে পারবেন যে, শেষ পর্যন্ত ব্লকটি একটি অ্যাপ্লিকেশন অনুকূলকরণ এবং মেমরি ফাঁস রোধ করার জন্য নকশা করা হয়েছিল।

সিএলআর সম্পূর্ণভাবে ফাঁসগুলি দূর করে না ... প্রোগ্রাম অযাচিতভাবে অযাচিত জিনিসগুলির রেফারেন্স রাখলে মেমরি ফাঁস হতে পারে

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

catchfinallyএই অর্থে পৃথক ছিল , ক্যাচ আপনাকে নিজের দ্বারা ত্রুটিটি পরিচালনা করার / পরিচালনা করার বা ব্যাখ্যা করার উপায় দেওয়ার নকশা ছিল। এটিকে এমন ব্যক্তি হিসাবে ভাবুন যিনি আপনাকে বলেছিলেন "আরে আমি কিছু খারাপ ছেলেকে ধরেছিলাম, আপনি তাদের সাথে আমার কী করতে চান?" যখন finallyনিশ্চিত করুন যে আপনার সম্পদ সঠিকভাবে স্থাপন করা হয় করতে পরিকল্পনা করা হয়েছিল। কারও কথা ভেবে দেখুন যে কিছু খারাপ লোক আছে কি না সে সে নিশ্চিত করবে যে আপনার সম্পত্তি এখনও নিরাপদ ছিল।

এবং আপনার সেই দুজনকে ভালোর জন্য একসাথে কাজ করার অনুমতি দেওয়া উচিত।

উদাহরণ স্বরূপ:

try
{
  StreamReader reader=new  StreamReader("myfile.txt");
  //do other stuff
}
catch(Exception ex){
 // Create log, or show notification
 generic.Createlog("Error", ex.message);
}
finally   // Will execute despite any exception
{
  reader.Close();
}

— dr.Crow
সূত্র

1

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

— Kibbee
সূত্র

1

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

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

0

সম্ভবত অনেক কারণের মধ্যে ব্যতিক্রমগুলি কার্যকর করতে খুব ধীর। যদি খুব বেশি কিছু ঘটে থাকে তবে আপনি সহজেই মৃত্যুদন্ড কার্যকর করতে পারেন।

— lotsoffreetime
সূত্র

0

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

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

— ডেভিড মহুন্দরো
সূত্র

0

আপনার উদাহরণগুলির মধ্যে কার্যকর পার্থক্য যতক্ষণ না ব্যতিক্রম ছোঁড়া হয় ততক্ষণ উপেক্ষিত।

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

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

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

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

using (StreamReader reader = new  StreamReader("myfile.txt"))
{
  int i = 5 / 0;
}

... যা স্ট্রিমরিডার উদাহরণটি বন্ধের বাইরে চলে যাবে এবং নিষ্পত্তি করবে। আশাকরি এটা সাহায্য করবে.

— জ্যারেড
সূত্র

0

চেষ্টা করুন {…} ধরা {always সবসময় খারাপ হয় না। এটি কোনও সাধারণ প্যাটার্ন নয়, তবে থ্রেডের শেষে (সম্ভবত) খোলা সকেটগুলি বন্ধ করার মতো বিষয়গুলি যখনই বন্ধ করার দরকার আছে তখন আমি এটি ব্যবহার করার ঝোঁক করি।

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