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

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

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

আসুন একটি ব্যতিক্রম তৈরি করি:


public class PhoneNumberAlreadyExistsException extends Exception {

   public PhoneNumberAlreadyExistsException(String message) {
       super(message);
   }
}
    

পরবর্তীতে আমরা আমাদের চেক করার সময় এটি ব্যবহার করব:


public class PhoneNumberRegisterService {
   List<String> registeredPhoneNumbers = Arrays.asList("+1-111-111-11-11", "+1-111-111-11-12", "+1-111-111-11-13", "+1-111-111-11-14");

   public void validatePhone(String phoneNumber) throws PhoneNumberAlreadyExistsException {
       if (registeredPhoneNumbers.contains(phoneNumber)) {
           throw new PhoneNumberAlreadyExistsException("The specified phone number is already in use by another customer!");
       }
   }
}
    

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


public class CreditCardIssue {
   public static void main(String[] args) {
       PhoneNumberRegisterService service = new PhoneNumberRegisterService();
       try {
           service.validatePhone("+1-111-111-11-14");
       } catch (PhoneNumberAlreadyExistsException e) {
           // Here we can write to logs or display the call stack
		e.printStackTrace();
       }
   }
}
    

এবং এখন সময় এসেছে Shift+F10 চাপার (যদি আপনি IDEA ব্যবহার করেন), অর্থাৎ প্রকল্পটি চালান। আপনি কনসোলে এটি দেখতে পাবেন:

exception.CreditCardIssue
exception.PhoneNumberAlreadyExistsException: নির্দিষ্ট ফোন নম্বরটি ইতিমধ্যেই অন্য গ্রাহকের দ্বারা ব্যবহার করা হচ্ছে!
ব্যতিক্রমে।PhoneNumberRegisterService.validatePhone(PhoneNumberRegisterService.java:11)

তোমার দিকে তাকাও! আপনি আপনার নিজের ব্যতিক্রম তৈরি করেছেন এবং এমনকি এটি কিছুটা পরীক্ষা করেছেন। এই অর্জনের জন্য অভিনন্দন! এটি কীভাবে কাজ করে তা আরও ভালভাবে বোঝার জন্য আমি কোডটি নিয়ে একটু পরীক্ষা করার পরামর্শ দিই।

আরেকটি চেক যোগ করুন - উদাহরণস্বরূপ, ফোন নম্বরে অক্ষর রয়েছে কিনা তা পরীক্ষা করুন। আপনি সম্ভবত জানেন, ফোন নম্বরগুলি মনে রাখা সহজ করতে মার্কিন যুক্তরাষ্ট্রে প্রায়শই অক্ষর ব্যবহার করা হয়, যেমন 1-800-MY-APPLE। আপনার চেক নিশ্চিত করতে পারে যে ফোন নম্বরে শুধুমাত্র নম্বর রয়েছে।

ঠিক আছে, তাই আমরা একটি চেক করা ব্যতিক্রম তৈরি করেছি। সব ঠিক এবং ভাল হবে, কিন্তু ...

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

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

এছাড়াও, আমরা "বয়লারপ্লেট" কোড দিয়ে শেষ করতে পারি, অর্থাৎ কোড যা অনেক জায়গা নেয়, কিন্তু খুব বেশি ভারী উত্তোলন করে না।

সমস্যাগুলি মোটামুটি বড় অ্যাপ্লিকেশনগুলিতে আবির্ভূত হয় যেখানে অনেকগুলি ব্যতিক্রমগুলি পরিচালনা করা হয়: একটি শীর্ষ-স্তরের পদ্ধতিতে থ্রো তালিকা সহজেই এক ডজন ব্যতিক্রম অন্তর্ভুক্ত করতে পারে।

সর্বজনীন OurCoolClass() FirstException, SecondException, ThirdException, ApplicationNameException নিক্ষেপ করে...

বিকাশকারীরা সাধারণত এটি পছন্দ করেন না এবং পরিবর্তে একটি কৌশল বেছে নেন: তারা তাদের সমস্ত চেক করা ব্যতিক্রমগুলিকে একটি সাধারণ পূর্বপুরুষের উত্তরাধিকারী করে তোলে — ApplicationNameException । এখন তাদের অবশ্যই একটি হ্যান্ডলারে সেই ( চেক করা !) ব্যতিক্রমটি ধরতে হবে:


catch (FirstException e) {
    // TODO
}
catch (SecondException e) {
    // TODO
}
catch (ThirdException e) {
    // TODO
}
catch (ApplicationNameException e) {
    // TODO
}
    

এখানে আমরা আরেকটি সমস্যার সম্মুখীন হলাম - শেষ ক্যাচ ব্লকে আমাদের কী করা উচিত? উপরে, আমরা ইতিমধ্যে সমস্ত প্রত্যাশিত পরিস্থিতি প্রক্রিয়া করেছি, তাই এই মুহুর্তে ApplicationNameException আমাদের কাছে " ব্যতিক্রম : কিছু বোধগম্য ত্রুটি ঘটেছে" ছাড়া আর কিছুই নয়। এইভাবে আমরা এটি পরিচালনা করি:


catch (ApplicationNameException e) {
    LOGGER.error("Unknown error", e.getMessage());
}
    

এবং শেষ পর্যন্ত, আমরা কি ঘটেছে জানি না.

কিন্তু আমরা কি সব ব্যতিক্রমকে একবারে নিক্ষেপ করতে পারি না, এভাবে?


public void ourCoolMethod() throws Exception {
// Do some work
}
    

হ্যাঁ আমরা করতে পারে. কিন্তু "ব্যতিক্রম নিক্ষেপ" আমাদের কি বলে? যে কিছু ভেঙ্গে গেছে. আপনাকে উপরের থেকে নীচে পর্যন্ত সবকিছু তদন্ত করতে হবে এবং কারণটি বোঝার জন্য দীর্ঘ সময়ের জন্য ডিবাগারের সাথে আরামদায়ক হতে হবে।

আপনি একটি নির্মাণের সম্মুখীন হতে পারেন যা কখনও কখনও "ব্যতিক্রম গ্রাস" বলা হয়:


try {
// Some code
} catch(Exception e) {
   throw new ApplicationNameException("Error");
}
    

ব্যাখ্যার মাধ্যমে এখানে যোগ করার মতো অনেক কিছু নেই — কোডটি সবকিছু পরিষ্কার করে, বা বরং, এটি সবকিছুকে অস্পষ্ট করে তোলে।

অবশ্যই, আপনি বলতে পারেন যে আপনি এটি বাস্তব কোডে দেখতে পাবেন না। আচ্ছা, আসুন java.net প্যাকেজ থেকে ইউআরএল ক্লাসের অন্ত্রের (কোড) দিকে তাকাই। আপনি যদি জানতে চান আমাকে অনুসরণ করুন!

এখানে ইউআরএল ক্লাসের একটি গঠন রয়েছে :


public URL(String spec) throws MalformedURLException {
   this(null, spec);
}
    

আপনি দেখতে পাচ্ছেন, আমাদের কাছে একটি আকর্ষণীয় চেক করা ব্যতিক্রম রয়েছে — MalformedURLException । এখানে যখন এটি নিক্ষেপ করা যেতে পারে (এবং আমি উদ্ধৃতি):
"যদি কোন প্রোটোকল নির্দিষ্ট করা না থাকে, বা একটি অজানা প্রোটোকল পাওয়া যায়, বা স্পেকটি নাল থাকে, বা পার্স করা URL সংশ্লিষ্ট প্রোটোকলের নির্দিষ্ট সিনট্যাক্স মেনে চলতে ব্যর্থ হয়।"

এটাই:

  1. যদি কোন প্রোটোকল নির্দিষ্ট করা না থাকে।
  2. একটি অজানা প্রোটোকল পাওয়া যায়.
  3. স্পেকটি শূন্য
  4. URL সংশ্লিষ্ট প্রোটোকলের নির্দিষ্ট সিনট্যাক্স মেনে চলে না।

আসুন একটি পদ্ধতি তৈরি করি যা একটি URL অবজেক্ট তৈরি করে:


public URL createURL() {
   URL url = new URL("https://codegym.cc");
   return url;
}
    

যত তাড়াতাড়ি আপনি IDE তে এই লাইনগুলি লিখবেন (আমি আইডিইএতে কোডিং করছি, তবে এটি Eclipse এবং NetBeans-তেও কাজ করে), আপনি এটি দেখতে পাবেন:

এর মানে হল আমাদের হয় একটি ব্যতিক্রম নিক্ষেপ করতে হবে, অথবা কোডটিকে একটি ট্রাই-ক্যাচ ব্লকে মোড়ানো দরকার। আপাতত, আমি কী ঘটছে তা কল্পনা করার জন্য দ্বিতীয় বিকল্পটি বেছে নেওয়ার পরামর্শ দিচ্ছি:


public static URL createURL() {
   URL url = null;
   try {
       url = new URL("https://codegym.cc");
   } catch(MalformedURLException e) {
  e.printStackTrace();
   }
   return url;
}
    

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

আমরা জাভাতে RuntimeException প্রসারিত করে একটি অচেক করা ব্যতিক্রম তৈরি করতে পারি ।

অচেক করা ব্যতিক্রমগুলি Error class বা RuntimeException ক্লাস থেকে উত্তরাধিকারসূত্রে প্রাপ্ত হয়। অনেক প্রোগ্রামার মনে করেন যে এই ব্যতিক্রমগুলি ক্যানড আমাদের প্রোগ্রামগুলিতে পরিচালনা করা যেতে পারে কারণ তারা এমন ত্রুটিগুলি উপস্থাপন করে যা আমরা প্রোগ্রামটি চলাকালীন পুনরুদ্ধারের আশা করতে পারি না।

যখন একটি অচেক করা ব্যতিক্রম ঘটে, এটি সাধারণত ভুলভাবে কোড ব্যবহার করে, নাল বা অন্যথায় অবৈধ যুক্তিতে পাস করার কারণে ঘটে।

আচ্ছা, আসুন কোডটি লিখি:


public class OurCoolUncheckedException extends RuntimeException {
   public OurCoolUncheckedException(String message) {
       super(message);
   }

   public OurCoolUncheckedException(Throwable cause) {
       super(cause);
   }
  
   public OurCoolUncheckedException(String message, Throwable throwable) {
       super(message, throwable);
   }
}
    

উল্লেখ্য যে আমরা বিভিন্ন উদ্দেশ্যে একাধিক কনস্ট্রাক্টর তৈরি করেছি। এটি আমাদের ব্যতিক্রমকে আরও ক্ষমতা দিতে দেয়। উদাহরণস্বরূপ, আমরা এটি তৈরি করতে পারি যাতে একটি ব্যতিক্রম আমাদের একটি ত্রুটি কোড দেয়। শুরুতে, আসুন আমাদের ত্রুটি কোডগুলি উপস্থাপন করার জন্য একটি enum তৈরি করি:


public enum ErrorCodes {
   FIRST_ERROR(1),
   SECOND_ERROR(2),
   THIRD_ERROR(3);

   private int code;

   ErrorCodes(int code) {
       this.code = code;
   }

   public int getCode() {
       return code;
   }
}
    

এখন আমাদের ব্যতিক্রম ক্লাসে আরেকটি কনস্ট্রাক্টর যোগ করা যাক:


public OurCoolUncheckedException(String message, Throwable cause, ErrorCodes errorCode) {
   super(message, cause);
   this.errorCode = errorCode.getCode();
}
    

এবং আসুন একটি ক্ষেত্র যোগ করতে ভুলবেন না (আমরা প্রায় ভুলে গেছি):


private Integer errorCode;
    

এবং অবশ্যই, এই কোড পেতে একটি পদ্ধতি:


public Integer getErrorCode() {
   return errorCode;
}
    

আসুন পুরো ক্লাসটি দেখি যাতে আমরা এটি পরীক্ষা করতে পারি এবং তুলনা করতে পারি:

public class OurCoolUncheckedException extends RuntimeException {
   private Integer errorCode;

   public OurCoolUncheckedException(String message) {
       super(message);
   }

   public OurCoolUncheckedException(Throwable cause) {
       super(cause);
   }

   public OurCoolUncheckedException(String message, Throwable throwable) {

       super(message, throwable);
   }

   public OurCoolUncheckedException(String message, Throwable cause, ErrorCodes errorCode) {
       super(message, cause);
       this.errorCode = errorCode.getCode();
   }
   public Integer getErrorCode() {
       return errorCode;
   }
}
    

তা-দা! আমাদের ব্যতিক্রম হয়েছে! আপনি দেখতে পাচ্ছেন, এখানে বিশেষ করে জটিল কিছু নেই। আসুন এটি কর্মে পরীক্ষা করে দেখি:


   public static void main(String[] args) {
       getException();
   }
   public static void getException() {
       throw new OurCoolUncheckedException("Our cool exception!");
   }
    

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

এখন আমাদের যোগ করা অতিরিক্ত কার্যকারিতার সুবিধা নেওয়া যাক। আমরা আগের কোডে একটু যোগ করব:


public static void main(String[] args) throws Exception {

   OurCoolUncheckedException exception = getException(3);
   System.out.println("getException().getErrorCode() = " + exception.getErrorCode());
   throw exception;

}

public static OurCoolUncheckedException getException(int errorCode) {
   return switch (errorCode) {
   case 1:
       return new OurCoolUncheckedException("Our cool exception! An error occurred: " + ErrorCodes.FIRST_ERROR.getCode(), new Throwable(), ErrorCodes.FIRST_ERROR);
   case 2:
       return new OurCoolUncheckedException("Our cool exception! An error occurred: " + ErrorCodes.SECOND_ERROR.getCode(), new Throwable(), ErrorCodes.SECOND_ERROR);
   default: // Since this is the default action, here we catch the third and any other codes that we have not yet added. You can learn more by reading Java switch statement
       return new OurCoolUncheckedException("Our cool exception! An error occurred: " + ErrorCodes.THIRD_ERROR.getCode(), new Throwable(), ErrorCodes.THIRD_ERROR);
}

}
    

আপনি ব্যতিক্রমগুলির সাথে একইভাবে কাজ করতে পারেন যেভাবে আপনি বস্তুর সাথে কাজ করেন। অবশ্যই, আমি নিশ্চিত যে আপনি ইতিমধ্যেই জানেন যে জাভাতে সবকিছুই একটি বস্তু।

এবং আমরা কি তাকান. প্রথমে, আমরা পদ্ধতিটি পরিবর্তন করেছি, যা এখন নিক্ষেপ করে না, বরং ইনপুট প্যারামিটারের উপর নির্ভর করে কেবল একটি ব্যতিক্রম তৈরি করে। এরপরে, একটি সুইচ-কেস স্টেটমেন্ট ব্যবহার করে, আমরা কাঙ্ক্ষিত ত্রুটি কোড এবং বার্তা সহ একটি ব্যতিক্রম তৈরি করি। এবং প্রধান পদ্ধতিতে, আমরা সৃষ্ট ব্যতিক্রম পাই, এরর কোড পাই এবং এটি নিক্ষেপ করি।

আসুন এটি চালাই এবং দেখুন আমরা কনসোলে কী পাই:

দেখুন - আমরা ব্যতিক্রম থেকে যে ত্রুটি কোডটি পেয়েছি তা প্রিন্ট করেছি এবং তারপর ব্যতিক্রমটি নিজেই ছুঁড়ে ফেলেছি। আরো কি, আমরা এমনকি ট্র্যাক করতে পারি ঠিক কোথায় ব্যতিক্রমটি নিক্ষেপ করা হয়েছিল। প্রয়োজন অনুসারে, আপনি বার্তাটিতে সমস্ত প্রাসঙ্গিক তথ্য যোগ করতে পারেন, অতিরিক্ত ত্রুটি কোড তৈরি করতে পারেন এবং আপনার ব্যতিক্রমগুলিতে নতুন বৈশিষ্ট্য যুক্ত করতে পারেন৷

আচ্ছা, আপনি যে কি মনে করেন? আমি আশা করি সবকিছু আপনার জন্য কাজ করেছে!

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

ব্রুস একেল তার বই "থিংকিং ইন জাভা" এর 12 অধ্যায়ে ব্যতিক্রম সম্পর্কে খুব ভাল লিখেছেন — আমি আপনাকে এটি পড়ার পরামর্শ দিচ্ছি! এছাড়াও হর্স্টম্যানের "কোর জাভা"-এর প্রথম ভলিউমটি দেখুন - এটি অধ্যায় 7-এ অনেক আকর্ষণীয় জিনিস রয়েছে।

একটি ছোট সারসংক্ষেপ

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

  2. ব্যতিক্রমের ক্ষেত্রে, তাদের সবাইকে একবারে ধরা খারাপ অভ্যাস (যেমন আমার একজন সহকর্মী বলেছেন, "এটি পোকেমন নয়, এটি জাভা"), তাই ধরা (ব্যতিক্রম e) বা খারাপ, ধরা (থ্রোয়েবল t) এড়িয়ে চলুন ।

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

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

  5. ব্যতিক্রমগুলি তখনই ধরুন যখন আপনি সেগুলিকে ব্যবহারকারীদের জন্য এবং ডিবাগিংয়ের জন্য কার্যকরভাবে পরিচালনা করতে পারেন৷

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

  7. আপনি যখন নিজের ব্যতিক্রম ক্লাস তৈরি করবেন, তখন নামকরণের ব্যাপারে সতর্ক থাকুন! আপনি সম্ভবত ইতিমধ্যেই জানেন যে ক্লাস, ভেরিয়েবল, পদ্ধতি এবং প্যাকেজগুলির সঠিক নামকরণ করা অত্যন্ত গুরুত্বপূর্ণ। ব্যতিক্রম কোন ব্যতিক্রম! :) সর্বদা ব্যতিক্রম শব্দটি দিয়ে শেষ করুন এবং ব্যতিক্রমের নামটি স্পষ্টভাবে বোঝানো উচিত যে এটি যে ধরনের ত্রুটি উপস্থাপন করে। উদাহরণস্বরূপ, FileNotFoundException

  8. আপনার ব্যতিক্রমগুলি নথিভুক্ত করুন। আমরা ব্যতিক্রমের জন্য @throws Javadoc ট্যাগ লেখার পরামর্শ দিই। এটি বিশেষভাবে উপযোগী হবে যখন আপনার কোড কোনো ধরনের ইন্টারফেস প্রদান করে। এবং আপনি পরে আপনার নিজের কোড বুঝতে আরও সহজ পাবেন। আপনি কি মনে করেন, আপনি কিভাবে নির্ধারণ করতে পারেন MalformedURLException কি? জাভাডক থেকে! হ্যাঁ, ডকুমেন্টেশন লেখার চিন্তাভাবনা খুব আকর্ষণীয় নয়, তবে বিশ্বাস করুন, ছয় মাস পরে যখন আপনি নিজের কোডে ফিরে আসবেন তখন আপনি নিজেকে ধন্যবাদ জানাবেন।

  9. রিলিজ রিসোর্স এবং অবহেলা করবেন না রিসোর্স নির্মাণের চেষ্টা করুন।

  10. এখানে সামগ্রিক সারাংশ: ব্যতিক্রমগুলি বুদ্ধিমানের সাথে ব্যবহার করুন। সম্পদের পরিপ্রেক্ষিতে একটি ব্যতিক্রম নিক্ষেপ করা মোটামুটি "ব্যয়বহুল" অপারেশন। অনেক ক্ষেত্রে, ব্যতিক্রমগুলি নিক্ষেপ করা এড়ানো সহজ হতে পারে এবং পরিবর্তে একটি বুলিয়ান ভেরিয়েবল ফিরে আসতে পারে যে অপারেশনটি সফল হয়েছে কিনা, একটি সহজ এবং "কম ব্যয়বহুল" if-else ব্যবহার করে ।

    এটি প্রয়োগের যুক্তিকে ব্যতিক্রমগুলির সাথে বেঁধে রাখতেও প্রলুব্ধ হতে পারে, যা আপনার স্পষ্টতই করা উচিত নয়৷ যেমনটি আমরা নিবন্ধের শুরুতে বলেছি, ব্যতিক্রমগুলি ব্যতিক্রমী পরিস্থিতির জন্য, প্রত্যাশিত নয় এবং তাদের প্রতিরোধ করার জন্য বিভিন্ন সরঞ্জাম রয়েছে। বিশেষ করে, একটি NullPointerException , বা Scanner.hasNext এবং এর মতো একটি IOException প্রতিরোধ করার জন্য ঐচ্ছিক আছে , যা read() পদ্ধতি নিক্ষেপ করতে পারে।