আপনার প্রদত্ত কোডটি এমন পরিস্থিতিতে বিবেচনা করুন:
public void delete() throws IOException, SQLException { // Non-Compliant
/* ... */
}
এখানে বিপদটি হ'ল আপনি যে কোডটি কল করতে লিখছেন delete()সেটির মতো দেখাবে:
try {
foo.delete()
} catch (Exception e) {
/* ... */
}
এটিও খারাপ। এবং এটি অন্য নিয়মের সাথে ধরা পড়বে যেগুলি বেস ব্যাতিক্রম শ্রেণীর পতাকাগুলি ধরে রাখে।
মূলটি হ'ল কোডটি লিখিত না যা আপনাকে অন্য কোথাও খারাপ কোড লিখতে চায়।
আপনি যে নিয়মের মুখোমুখি হচ্ছেন তা একটি সাধারণ বিষয়। চেকস্টাইলটিতে এটির নকশার নিয়ম রয়েছে:
ThrowsCount
নির্দিষ্ট গুনে স্ট্রোটমেন্টগুলিকে সীমাবদ্ধ করে (ডিফল্টরূপে 1)।
যুক্তি: ব্যতিক্রম একটি পদ্ধতির ইন্টারফেসের অংশ গঠন করে। অনেকগুলি ভিন্ন ভিন্ন শিকড় ব্যতিক্রম ছুঁড়ে ফেলার পদ্ধতি ঘোষণা করা ব্যতিক্রমকে কঠোরভাবে পরিচালনা করে তোলে এবং ক্যাচ (লিখিত ব্যতিক্রম) এর মতো লিখনের কোডের মতো প্রোগ্রামিংয়ের অনুশীলনগুলিতে বাড়ে। এই চেকটি বিকাশকারীদেরকে একটি শ্রেণিবিন্যাসের ব্যতিক্রম রাখতে বাধ্য করে যেমন সহজতম ক্ষেত্রে, কেবলমাত্র এক ধরণের ব্যতিক্রম একজন কলকারী দ্বারা পরীক্ষা করা প্রয়োজন তবে প্রয়োজনে যে কোনও সাবক্লাস বিশেষভাবে ধরা যেতে পারে।
এটি সমস্যাটি এবং সমস্যাটি কী এবং আপনার এটি কেন করা উচিত নয় তা স্পষ্টভাবে বর্ণনা করে। এটি একটি স্বীকৃত মান যে অনেক স্থিতিশীল বিশ্লেষণ সরঞ্জাম সনাক্ত এবং পতাকাঙ্কিত করবে।
আপনি যখন ভাষা নকশা অনুসারে এটি করতে পারেন এবং এমন সময় হতে পারে যখন এটি করা সঠিক জিনিস হয় তবে এটি এমন কিছু যা আপনার দেখা উচিত এবং অবিলম্বে "উম, আমি কেন এটি করছি?" এটি অভ্যন্তরীণ কোডের জন্য গ্রহণযোগ্য হতে পারে যেখানে প্রত্যেকেই কখনই পর্যাপ্ত শৃঙ্খলাবদ্ধ না হয় catch (Exception e) {}, তবে প্রায়শই আমি লোকেরা বিশেষত অভ্যন্তরীণ পরিস্থিতিতে কর্নার কাটতে দেখিনি।
আপনার শ্রেণীর ব্যবহারকারী লোকগুলিকে খারাপ কোড লিখতে চান না।
আমার উল্লেখ করতে হবে যে জাভা এসই 7 এর সাথে এর গুরুত্ব কম হয়েছে কারণ একক ক্যাপ স্টেটমেন্ট একাধিক ব্যতিক্রম ( ওরেল থেকে উন্নত প্রকারের চেকিংয়ের সাথে একাধিক ব্যতিক্রমের ধরণ এবং পুনর্বিবেচনা ব্যতিক্রমগুলি ) ধরতে পারে catch
জাভা 6 এবং এর আগে, আপনার কাছে এমন কোড থাকবে যা দেখতে দেখতে লাগবে:
public void delete() throws IOException, SQLException {
/* ... */
}
এবং
try {
foo.delete()
} catch (IOException ex) {
logger.log(ex);
throw ex;
} catch (SQLException ex) {
logger.log(ex);
throw ex;
}
অথবা
try {
foo.delete()
} catch (Exception ex) {
logger.log(ex);
throw ex;
}
জাভা 6 সহ এই বিকল্পগুলির কোনওটিই আদর্শ নয়। প্রথম পদ্ধতির DRY লঙ্ঘন করে । একাধিক ব্লক একই জিনিস করছে, বার বার - প্রতিটি ব্যতিক্রম একবার। আপনি কি ব্যতিক্রমটি লগ ইন করতে চান এবং এটি পুনরায় পুঙ্খানুপুঙ্খ করতে চান? ঠিক আছে. প্রতিটি ব্যতিক্রমের জন্য কোডের একই লাইন।
দ্বিতীয় বিকল্পটি বেশ কয়েকটি কারণে খারাপ। প্রথমত, এর অর্থ হ'ল আপনি সমস্ত ব্যতিক্রমগুলি ধরছেন। নাল পয়েন্টার সেখানে ধরা পড়ে (এবং এটি করা উচিত নয়)। উপরন্তু, আপনি একটি rethrowing হয় Exceptionযার মানে পদ্ধতি স্বাক্ষর হবে deleteSomething() throws Exceptionযা শুধু আপনার কোড ব্যবহার এখন হয় স্ট্যাক আপ আরও একটি জগাখিচুড়ি তোলে বাধ্য করার catch(Exception e)।
জাভা 7 সঙ্গে, এই নয় হিসাবে কারণ আপনার পরিবর্তে কি করতে পারেন গুরুত্বপূর্ণ:
catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}
তদুপরি, টাইপ চেকিং যদি কেউ ফেলে দেওয়া ব্যতিক্রমগুলির ধরণগুলি ধরা দেয় তবে :
public void rethrowException(String exceptionName)
throws IOException, SQLException {
try {
foo.delete();
} catch (Exception e) {
throw e;
}
}
টাইপ পরীক্ষক যে চিনতে পারবে eপারে শুধুমাত্র ধরনের হতে IOExceptionবা SQLException। আমি এখনও এই স্টাইলের ব্যবহার সম্পর্কে অত্যধিক উত্সাহী নই, তবে এটি জাভা 6 এর অধীনে যেমন খারাপ কোড তৈরি করছে না (যেখানে এটি আপনাকে মেথডের স্বাক্ষরটি ব্যতিক্রমগুলি প্রসারিত করে এমন সুপারক্লাস হতে বাধ্য করবে)।
এই সমস্ত পরিবর্তন সত্ত্বেও, অনেক স্থিতিশীল বিশ্লেষণ সরঞ্জাম (সোনার, পিএমডি, চেকস্টাইল) এখনও জাভা 6 স্টাইলের গাইড প্রয়োগ করছে। এটি কোনও খারাপ জিনিস নয়। এগুলি এখনও কার্যকর করার জন্য আমি একটি সতর্কতার সাথে একমত হতে চাই তবে আপনার দল কীভাবে তাদের অগ্রাধিকার দেয় সে অনুযায়ী আপনি তাদের উপর অগ্রাধিকার মেজর বা অপ্রাপ্তবয়স্কে পরিবর্তন করতে পারেন।
ব্যতিক্রম চেক করা উচিত যদি বা অবারিত ... যেটা ব্যাপার ছ দ ই একটি টন বিতর্ক যে এক সহজে যুক্তি প্রতিটি পাশ গ্রহণ অগণিত ব্লগ পোস্ট খুঁজে পাচ্ছি না। তবে, আপনি যদি চেক করা ব্যতিক্রম নিয়ে কাজ করছেন, আপনার সম্ভবত কমপক্ষে জাভা 6 এর অধীনে একাধিক প্রকারের ছোঁড়া এড়ানো উচিত।