কোডটিতে রানটাইম ব্যতিক্রমগুলি পরিচালনা করা কি ভাল অনুশীলন নয়?

Question

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

try {
    // do something
} catch(NullPointerException e) {
    return null;
}

আমার প্রশ্নগুলি হল, রানটাইম ব্যতিক্রমগুলি পরিচালনা করা কখন ভাল অনুশীলন? ব্যতিক্রম কবে না ছাড়তে হবে?

Comments

-1: এই বিস্তৃত এবং অস্পষ্ট প্রশ্নের কোনও উত্তর নেই। এটি এত অবিচ্ছিন্ন প্রশ্নের কোনও একক উত্তর সরবরাহ করা অসম্ভব। এই প্রশ্নটি ভয়াবহ। অনুগ্রহ করে নির্দিষ্ট আপনি সন্দেহ আছে যেখানে উদাহরণ।

— এস .লট

@ এস.লট আমি এক্ষেত্রে একমত নই, কারণ মনে হয় প্রোগ্রামারদের একটি উপসেট আছে যা তাদের মাথায় রয়েছে যে এটি "ভাল" যুক্তিবাদী নয়।

— SoylentGray

@ চ্যাড: "এটি" ভাল "যুক্তিবাদীতা" নয়। এটা সত্য হতে পারে। তবে সম্ভাব্য একমাত্র উত্তর হতে হবে "এটি নির্ভর করে"। সুতরাং, প্রশ্নটি ত্রুটিযুক্ত বলে মনে হচ্ছে।

— এস .লট

Answer 1

এটা নির্ভর করে.

উদাহরণস্বরূপ, প্রদত্ত স্ট্রিংটিকে বিশ্লেষণ করতে না পারলে Integer#parseIntনিক্ষেপ NumberFormatException(যা একটি আরটিই)। তবে অবশ্যই আপনি চান না যে আপনার অ্যাপ্লিকেশনটি ক্র্যাশ হ'ল কারণ ব্যবহারকারী কোনও পাঠ্য ক্ষেত্রে "x" লিখেছেন যা পূর্ণসংখ্যার জন্য ছিল? এবং আপনি কীভাবে জানেন যে স্ট্রিংটি বিশ্লেষণ করা যায় কিনা আপনি প্রথমে পার্স করার চেষ্টা না করলে? সুতরাং এই ক্ষেত্রে, আরটিই হ'ল একটি ত্রুটি সংকেত যা কোনও প্রকার ত্রুটি বার্তা তৈরি করে। কেউ তর্ক করতে পারে যে এটি একটি চেক করা ব্যতিক্রম হওয়া উচিত , তবে আপনি কী করতে পারেন - এটি তা নয়।

Comments

আমি "এটি নির্ভর করে" এর সাথে একমত, তবে আপনার পার্সিং উদাহরণটি খারাপ এপিআই ডিজাইনের ক্ষেত্রে বলে মনে হচ্ছে। Integer#parseIntএর Maybe<Integer>পরিবর্তে সত্যিকার অর্থে ফিরে আসা উচিত এবং কোনও ব্যতিক্রম এড়াতে হবে না।

— জার্গ ডব্লু মিটাগ

@ জার্গ ডব্লু মিটাগ: আমি সম্মত হই যে এটি খারাপ এপিআই নকশা, তবে আমাদের এটিই বাস্তব জগতকে মোকাবেলা করতে হবে। কিভাবে ঠিকমতো throwables হ্যান্ডেল করতে / রিটার্ন মান কিভাবে বিশ্বের উপর নির্ভর করে আসলে কাজ করে, না এটা কিভাবে সন্তোষজনক ভাবে উপর উচিত কাজ :-)

— Joonas Pulakka

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

— জারজেন স্ট্রোবল

Answer 2

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

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

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

Comments

আমি যুক্ত করতে চাই যে নাল চেক একটি ভাল সিদ্ধান্তের পারফরম্যান্স ভিত্তিক।

— মাহমুদ হোসাম

... তবুও, যদি আপনি কয়েক ডজন বরাদ্দ করে থাকেন যা এক জায়গায় "কখনই ব্যর্থ হয় না", তাদের প্রত্যেকের জন্য নাল চেক যুক্ত করা হাস্যকরভাবে কোডটি অবলম্বন করতে পারে। একটি ক্যাচ-অল ব্যতিক্রম (যে পরিস্থিতিটি করুণভাবে পরিচালনা করবে, কেবল নয় return null;) আরও ভাল সমাধান হবে।

— এসএফ

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

— ডেডালনিক্স

newstd::bad_allocসি ++ এ ছোঁড়ে ।

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

ধরে নিচ্ছি যে নতুন অপারেটর অত্যধিক বোঝা নয়, যা সাধারণ অভ্যাস। সি ++ এ, যে কোনও কিছু ঘটতে পারে;) তবে ঠিক আছে, আসুন সি এর ম্যালোক বলি। গুরুত্বপূর্ণ বিষয়টি ছিল আপনি জাভাতে পান নি।

— ডেডালনিক্স

Answer 3

আমি প্রত্যাশিত ব্যতিক্রমগুলি যেখানে পরিচালনা করি তা তাদের পরিচালনা করি। (ডিবি পড়ার / লেখার ত্রুটির মতো)। অপ্রত্যাশিত ব্যতিক্রম আমি বুদবুদ। অন্য কোথাও ব্যতিক্রমটি প্রত্যাশা করে এবং এর জন্য যুক্তি থাকতে পারে।

Answer 4

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

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

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

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

Integer getUserCount() {
   Integer result = null;
   try {
      // Attempt to open database and retrieve data
   } catch (TimeoutException e) {
      logger.error("Got a watch?");
   } catch (MissingDatabaseException e) {
      logger.error("What are you smoking?");
   } catch (PermissionsToReadException e) {
      logger.error("Did you *really* think you were getting away with that?");
   } catch (PressedSendButtonToHardException e) {
      logger.error("Seriously.. just back away from the computer... slowly..");
   } catch (WTFException e) {
      logger.error("You're on your own with this one.. I don't even know what happened..");
   } finally {
      // Close connections and whatnot
   }
   return result;
}

void doStuff() {
   Integer result = getUserCount();
   if(result != null) {
       // Went as planned..
   }
}

Comments

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

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

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

— টমাসের মালিক

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

— ডেডালনিক্স

@ ডিডালনিক্স: আমি তর্ক করতে পারি যে আপনি অন্যথায় চেষ্টা করেও সহজেই ভুলে যেতে পারেন। পার্থক্য শৈলীর বিষয়, কার্যকারিতা নয়।

— নীল

@ ইম্মকিউ: আমি একমত নই আমার মনে হয় আপনার ফাইল.এক্সিস্টগুলি () ব্যবহার করা উচিত এবং বিরল পরিস্থিতিতে এটি ব্যবহার করার আগে এটি মুছে ফেলা হয়, একটি ব্যতিক্রম উপযুক্তের চেয়ে বেশি। পার্থক্য হ'ল আপনি কোথায় নিজের ক্যাচ রেখেছেন। এটি লগ এবং রিপোর্ট করতে অপ্রত্যাশিত ত্রুটি জন্য কেবল একটি কম্বল ব্যতিক্রম ক্যাচার আছে।

— নীল

Answer 5

হ্যাঁ আপনি সঠিকভাবে পরিচালনা করছেন রান টাইম ব্যতিক্রমগুলি ভাল অনুশীলন নয় reason কারণ এটি এটিকে ব্যয়বহুল / স্মৃতিশক্তি হিসাবে বিবেচনা করা হয়।

Comments

হাই প্রসী, আপনি কি নিজের উত্তরটি বিস্তারিত বলতে পারবেন? ওয়ান-লাইনার যা তথ্য, তথ্যসূত্র বা অভিজ্ঞতার সাথে ব্যাক আপ হয় না খুব কার্যকর নয়।