ব্যতিক্রম পরিচালনা করার জন্য কয়েকটি নিয়ম রয়েছে যা আপনার মনে রাখা উচিত। তবে প্রথমে আপনাকে মনে রাখতে হবে যে ব্যতিক্রমগুলি কোড দ্বারা প্রকাশিত ইন্টারফেসের অংশ ; তাদের নথি । এটি বিশেষত গুরুত্বপূর্ণ যখন ইন্টারফেসটি অবশ্যই সর্বজনীন হয় তবে এটি ব্যক্তিগত ইন্টারফেসেও খুব ভাল ধারণা।
ব্যতিক্রমগুলি কেবলমাত্র সেই বিন্দুতে পরিচালনা করা উচিত যেখানে কোডটি তাদের সাথে বুদ্ধিমান কিছু করতে পারে। সবচেয়ে খারাপ হ্যান্ডলিং বিকল্পটি তাদের সম্পর্কে কিছু না করা, যা কেবল তখনই করা উচিত যখন এটি সঠিক বিকল্প। (আমার কোডে আমার যখন এমন পরিস্থিতি হয় তখন আমি সে বিষয়ে একটি মন্তব্য অন্তর্ভুক্ত করি যাতে খালি শরীর সম্পর্কে চিন্তা করতে আমি জানি না))
দ্বিতীয়টি সবচেয়ে খারাপ বিকল্প হ'ল কারণ হিসাবে সংযুক্ত আসল ব্যতীত কোনও সম্পর্কযুক্ত ব্যতিক্রম নিক্ষেপ করা। এখানে সমস্যাটি হ'ল মূল ব্যতিক্রমের মধ্যে থাকা সমস্যাগুলি যা সমস্যার সনাক্তকরণের অনুমতি দেয়; আপনি এমন কিছু তৈরি করছেন যা দিয়ে কেউ কিছুই করতে পারে না ("এটি কাজ করে না" এমন অভিযোগ ছাড়াও, এবং আমরা সকলেই জানি যে আমরা কীভাবে এই বাগ রিপোর্টগুলিকে ঘৃণা করি )।
ব্যতিক্রম লগ করা অনেক ভাল। এটি কাউকে সমস্যাটি কী তা খুঁজে পেতে এবং এটি ঠিক করতে দেয় তবে আপনার ব্যতিক্রমটি কেবলমাত্র সেই বিন্দুতে লগ করা উচিত যেখানে এটি অন্যথায় হারিয়ে যায় বা বাহ্যিক সংযোগে রিপোর্ট করা হয়। এর কারণ এটি নয় যে প্রায়শই লগইন করা যেমন একটি বড় সমস্যা, বরং অতিরিক্ত লগিংয়ের অর্থ আপনি লগকে আরও তথ্য ব্যতীত আরও বেশি জায়গা ব্যয় করতে পারেন। আপনি ব্যতিক্রমটি লগ ইন করার পরে, আপনি একটি ভাল বিবেকের সাথে ব্যবহারকারী / ক্লায়েন্টের কাছে প্রিসিসের প্রতিবেদন করতে পারেন (যতক্ষণ না আপনি প্রজন্মের সময়ও অন্তর্ভুক্ত করেন - বা অন্যান্য সম্পর্ক সম্পর্কিত সনাক্তকারী - সেই প্রতিবেদনে যাতে সংক্ষিপ্ত সংস্করণটি মিলে যায় প্রয়োজনে বিশদটি সহ আপ করুন)।
অবশ্যই সেরা বিকল্পটি সম্পূর্ণরূপে ত্রুটি পরিস্থিতি মোকাবেলা করে ব্যতিক্রমটিকে পুরোপুরি পরিচালনা করা। আপনি যদি এটি করতে পারেন তবে সর্বদা এটি করুন! এমনকি এটির অর্থও হতে পারে যে আপনি ব্যতিক্রমটি লগ করতে এড়াতে পারেন।
একটি ব্যতিক্রম হ্যান্ডেল করার একটি উপায় হ'ল আরেকটি ব্যতিক্রম ছুঁড়ে দেওয়া যা সমস্যার উচ্চ-স্তরের বর্ণনা সরবরাহ করে (যেমন, " failed to initialize" পরিবর্তে " index out of bounds" " ")। আপনি যতক্ষণ ব্যতিক্রমের কারণ সম্পর্কে তথ্য হারাবেন না ততক্ষণ এটি একটি নিদর্শন; causeউচ্চ-স্তরের ব্যতিক্রমটি শুরু করতে বিশদ ব্যতিক্রমটি ব্যবহার করুন বা বিশদটি লগ করুন (উপরে আলোচনা হিসাবে)। লগিং সর্বাধিক উপযুক্ত যখন আপনি আন্তঃ-প্রক্রিয়া সীমানা অতিক্রম করতে চলেছেন যেমন আইপিসি কল, কারণ কোনও গ্যারান্টি নেই যে সংযোগের অন্য প্রান্তে নিম্ন-স্তরের ব্যতিক্রম শ্রেণি উপস্থিত থাকবে। অভ্যন্তরীণ সীমানা অতিক্রম করার সময় কোনও সংযুক্ত কারণ হিসাবে রাখা সবচেয়ে উপযুক্ত।
আপনি দেখতে পেলেন এমন অন্য প্যাটার্নটি হ'ল ক্যাচ-রিলিজ:
try {
// ...
} catch (FooException e) {
throw e;
}
এটি একটি বিরোধী-নিদর্শন না হয়ে থাকে যদি না আপনি অন্য catchক্লজগুলি থেকে টাইপ সীমাবদ্ধতা পেয়ে থাকেন যার অর্থ আপনি কেবল ব্যতিক্রমটিকে নিজের মতো করে যেতে দিতে পারবেন না। তারপরে এটি জাভার একটি কুৎসিত বৈশিষ্ট্য।
চেক করা ব্যতিক্রম এবং চেক করা ব্যতীত কোনও সত্য পার্থক্য নেই এই সত্যটি ছাড়াও যে আপনাকে অবশ্যই ক্রস পদ্ধতির সীমানা যাচাই করা ব্যতিক্রমগুলি ঘোষণা করতে হবে । @throwsআপনার কোড দ্বারা ইচ্ছাকৃতভাবে ছুঁড়ে ফেলা হচ্ছে যদি আপনি জানেন তবে চেক করা ব্যতিক্রমগুলি ( জাভাদোকের মন্তব্য সহ) নথিভুক্ত করা এখনও ভাল ধারণা । ইচ্ছাকৃতভাবে নিক্ষেপ করবেন না java.lang.Errorবা এর সাবক্লাসগুলি (আপনি যদি কোনও জেভিএম বাস্তবায়ন না লিখে থাকেন)।
মতামত: একটি অপ্রত্যাশিত ত্রুটি মামলা সর্বদা আপনার কোডটিতে একটি বাগ প্রদর্শন করে। চেক করা ব্যতিক্রমগুলি হুমকিটি পরিচালনা করার একটি উপায় এবং যেখানে বিকাশকারীরা ত্রুটিযুক্ত মামলাগুলি পরিচালনা করার ঝামেলা এড়াতে ইচ্ছাকৃতভাবে চেক করা ব্যতিক্রমগুলি ব্যবহার করছেন, আপনি বেশ কিছু প্রযুক্তিগত debtণ তৈরি করছেন যা আপনাকে কিছুটা সময় সাফ করতে হবে have আপনি যদি শক্ত কোড চান। স্লোপি ত্রুটি হ্যান্ডলিং অযৌক্তিক (এবং ত্রুটি পরিচালনার দিকে তাকানো একটি প্রোগ্রামার সত্যই কতটা ভাল তা নির্ধারণ করার একটি ভাল উপায়)।