টি এল; ডিআর
প্রতিজ্ঞা
- ত্রুটিটি অপরিশোধনযোগ্য হলে রানটাইম ব্যতিক্রমগুলি ছুঁড়ে ফেলা উচিত: যখন ত্রুটি কোডে থাকে এবং এটি বাহ্যিক অবস্থার উপর নির্ভর করে না (সুতরাং, পুনরুদ্ধার কোডটি সংশোধন করবে)।
- কোডটি সঠিক হলে চেক করা ব্যতিক্রমগুলি নিক্ষেপ করা উচিত, তবে বাহ্যিক অবস্থা প্রত্যাশার মতো নয়: কোনও নেটওয়ার্ক সংযোগ নেই, ফাইল পাওয়া যায় নি বা দুর্নীতিগ্রস্থ নয়, ইত্যাদি
উপসংহার
আমরা একটি রানটাইম ব্যতিক্রম হিসাবে একটি চেক করা ব্যতিক্রম পুনর্বিবেচনা করতে পারি যদি প্রচার বা ইন্টারফেস কোড ধরে নেওয়া হয় যে অন্তর্নিহিত বাস্তবায়ন বাহ্যিক অবস্থার উপর নির্ভর করে, যখন এটি পরিষ্কারভাবে হয় না।
এই বিভাগটি কখন ব্যতিক্রম দুটি নিক্ষেপ করা উচিত সে বিষয়ে আলোচনা করেছে। আপনি যদি উপসংহারের জন্য আরও বিস্তৃত ব্যাখ্যাটি পড়তে চান তবে আপনি পরবর্তী অনুভূমিক বারে যেতে পারেন।
কখন রানটাইম ব্যতিক্রম নিক্ষেপ করা উপযুক্ত? কোডটি ভুল রয়েছে তা স্পষ্ট হয়ে গেলে আপনি একটি রানটাইম ব্যতিক্রম ছুঁড়ে মারেন এবং কোডটি সংশোধন করে সেই পুনরুদ্ধারটি উপযুক্ত।
উদাহরণস্বরূপ, নিম্নলিখিতগুলির জন্য একটি রানটাইম ব্যতিক্রম নিক্ষেপ করা উপযুক্ত:
float nan = 1/0;
এটি শূন্য রানটাইম ব্যতিক্রম দ্বারা একটি বিভাগ ফেলবে। কোডটি ত্রুটিযুক্ত হওয়ায় এটি উপযুক্ত ।
বা উদাহরণস্বরূপ, এখানে এর HashMapনির্মাণকারীর একটি অংশ :
public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
// more irrelevant code...
}
প্রাথমিক ক্ষমতা বা লোড ফ্যাক্টরটি স্থির করার জন্য, সঠিক মানগুলি পাস হচ্ছে তা নিশ্চিত করার জন্য আপনার কোডটি সম্পাদনা করা উপযুক্ত It এটি ডিস্কের বর্তমান অবস্থার উপর কিছুটা দূরে সার্ভারের উপর নির্ভর করে না, একটি ফাইল, বা অন্য প্রোগ্রাম। সেই কনস্ট্রাক্টরকে অবৈধ আর্গুমেন্ট সহ ডাকা হচ্ছে কলিং কোডের সঠিকতার উপর নির্ভর করে, এটি কোনও ভুল গণনা হতে পারে যা অবৈধ পরামিতি বা অনুপযুক্ত প্রবাহকে ত্রুটি মিস করে।
কখন চেক করা ব্যতিক্রম নিক্ষেপ করা উপযুক্ত? যখন বিষয়টি আপনাকে অবশ্যই একটি চেক করা ব্যতিক্রম নিক্ষেপ হয় কোড পরিবর্তন না করে আদায়যোগ্য। অথবা এটিকে বিভিন্ন পদে রাখতে, কোডটি সঠিক হওয়ার সাথে সাথে ত্রুটি রাষ্ট্রের সাথে সম্পর্কিত হলে আপনি একটি পরীক্ষিত ব্যতিক্রম ছুঁড়ে ফেলেন।
এখন "পুনরুদ্ধার" শব্দটি এখানে জটিল। এর অর্থ এই হতে পারে যে আপনি লক্ষ্য অর্জনের জন্য অন্য কোনও উপায় খুঁজে পেয়েছেন: উদাহরণস্বরূপ, সার্ভার যদি সাড়া না দেয় তবে আপনার পরবর্তী সার্ভারটি চেষ্টা করা উচিত। যদি এই ধরণের পুনরুদ্ধার আপনার ক্ষেত্রে সম্ভব হয় তবে এটি দুর্দান্ত, তবে পুনরুদ্ধারের অর্থ কেবল এটিই নয় - পুনরুদ্ধারটি কেবল ব্যবহারকারীকে একটি ত্রুটি সংলাপ প্রদর্শন করে যা ঘটেছে তা ব্যাখ্যা করে, বা যদি এটি কোনও সার্ভার অ্যাপ্লিকেশন হয় তবে এটি হতে পারে প্রশাসকের কাছে ইমেল প্রেরণ করা, বা এমনকি ত্রুটিটি যথাযথভাবে এবং সংক্ষিপ্তভাবে লগ করা।
মিঃ মগগলসের উত্তরে উল্লিখিত উদাহরণটি নেওয়া যাক:
public void dataAccessCode(){
try{
..some code that throws SQLException
}catch(SQLException ex){
throw new RuntimeException(ex);
}
}
চেক করা ব্যতিক্রমটি পরিচালনা করার জন্য এটি সঠিক উপায় নয়। এই পদ্ধতির সুযোগে ব্যতিক্রমটি সামলানোর কেবলমাত্র অক্ষমতা মানেই এই নয় যে অ্যাপটি ক্র্যাশ করা উচিত। পরিবর্তে, এটি এর মতো উচ্চতর স্কোপে প্রচার করা উপযুক্ত:
public Data dataAccessCode() throws SQLException {
// some code that communicates with the database
}
যা কলারের মাধ্যমে পুনরুদ্ধারের সম্ভাবনার পক্ষে অনুমতি দেয়:
public void loadDataAndShowUi() {
try {
Data data = dataAccessCode();
showUiForData(data);
} catch(SQLException e) {
// Recover by showing an error alert dialog
showCantLoadDataErrorDialog();
}
}
চেক করা ব্যতিক্রমগুলি একটি স্ট্যাটিক-অ্যানালাইসিস হাতিয়ার, তারা প্রোগ্রামারকে এটি পরিষ্কার করে দেয় যে কোনও প্রয়োগে তাদের প্রয়োগ শিখতে বা পরীক্ষার এবং ত্রুটি প্রক্রিয়াটি না শিখিয়ে কোনও নির্দিষ্ট কলে কী ভুল হতে পারে। ত্রুটি প্রবাহের কোনও অংশ উপেক্ষা করা হবে না তা নিশ্চিত করা এটি সহজ করে তোলে। রানটাইম ব্যতিক্রম হিসাবে একটি পরীক্ষিত ব্যতিক্রমটিকে পুনরায় সরানো এই শ্রম-সঞ্চয়কারী স্থিতিশীল বিশ্লেষণ বৈশিষ্ট্যের বিরুদ্ধে কাজ করছে।
এটিও উল্লেখযোগ্য যে, কলিং স্তরটির উপরে গ্র্যান্ডার স্কিমের আরও ভাল প্রসঙ্গ রয়েছে যা উপরে প্রদর্শিত হয়েছে। এর জন্য dataAccessCodeডাকা হওয়ার অনেকগুলি কারণ থাকতে পারে, কল করার নির্দিষ্ট কারণটি কেবলমাত্র কলারের কাছে দৃশ্যমান ler এইভাবে ব্যর্থতার পরে সঠিক পুনরুদ্ধারে এটি আরও ভাল সিদ্ধান্ত নিতে সক্ষম হয় make
এখন যেহেতু আমরা এই পার্থক্যটি স্পষ্ট পেয়েছি, রানটাইম ব্যতিক্রম হিসাবে চেক করা ব্যতিক্রমটিকে পুনর্বিবেচনা করা ঠিক হয়ে গেলে আমরা অনুমান করতে এগিয়ে যেতে পারি।
উপরের দিক থেকে দেওয়া, কখন রানটাইম এক্সেকশন হিসাবে চেক করা ব্যতিক্রমটি পুনর্বার করা উপযুক্ত? আপনি যে কোডটি ব্যবহার করছেন তা যখন বাহ্যিক অবস্থার উপর নির্ভরতা অনুমান করে তবে আপনি পরিষ্কারভাবে জোর দিয়ে বলতে পারেন যে এটি বাহ্যিক অবস্থার উপর নির্ভর করে না।
নিম্নোক্ত বিবেচনা কর:
StringReader sr = new StringReader("{\"test\":\"test\"}");
try {
doesSomethingWithReader(sr); // calls #read, so propagates IOException
} catch (IOException e) {
throw new IllegalStateException(e);
}
এই উদাহরণে, কোডটি প্রচার করছে IOExceptionকারণ এর এপিআই Readerবাহ্যিক স্থিতি অ্যাক্সেস করার জন্য ডিজাইন করা হয়েছে, তবে আমরা জানি যে StringReaderবাস্তবায়ন বাহ্যিক অবস্থানে অ্যাক্সেস করে না। এই সুযোগে, যেখানে আমরা অবশ্যই দৃ can়ভাবে বলতে পারি যে কলটিতে জড়িত অংশগুলি IO বা অন্য কোনও বাহ্যিক অবস্থানে অ্যাক্সেস পাচ্ছে না, আমরা আমাদের প্রয়োগ সম্পর্কে অসচেতন অবাক বিস্মৃত সহকর্মীদের ব্যতীত নিরাপদে ব্যতিক্রমটিকে রানটাইম ব্যতিক্রম হিসাবে পুনর্বিবেচনা করতে পারি (এবং সম্ভবত ধরে নিই যে আইও-অ্যাক্সেসিং কোডটি একটি নিক্ষেপ করবে IOException)।
বাহ্যিক রাষ্ট্রের নির্ভরশীল ব্যতিক্রমগুলি কঠোরভাবে চেক রাখার কারণ হ'ল তারা অ-নিরস্তাত্মক (যুক্তির উপর নির্ভরশীল ব্যতিক্রমগুলি থেকে পৃথক, যা সম্ভবত কোডের কোনও সংস্করণের জন্য প্রতিবারই পুনরুত্পাদন করা হবে)। উদাহরণস্বরূপ, আপনি যদি 0 দ্বারা ভাগ করার চেষ্টা করেন তবে আপনি সর্বদা একটি ব্যতিক্রম তৈরি করবেন। আপনি যদি 0 দ্বারা ভাগ না করেন তবে আপনি কখনই একটি ব্যতিক্রম তৈরি করতে পারবেন না এবং আপনাকে এই ব্যতিক্রম মামলাটি পরিচালনা করতে হবে না, কারণ এটি কখনই ঘটবে না। কোনও ফাইল অ্যাক্সেসের ক্ষেত্রে, তবে একবার সফল হওয়ার অর্থ এই নয় যে আপনি পরের বার সফল হবেন - ব্যবহারকারীর অনুমতিগুলি পরিবর্তিত হতে পারে, অন্য কোনও প্রক্রিয়া এটি মুছে ফেলে বা সংশোধন করেছে। সুতরাং আপনাকে সর্বদা সেই ব্যতিক্রমী কেসটি পরিচালনা করতে হবে, অথবা আপনার সম্ভবত কোনও বাগ রয়েছে।