உங்கள் சொந்த விதிவிலக்குகளை உருவாக்குதல்

நீங்கள் குறியீட்டை இயக்கி, 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 ஐப் பயன்படுத்துகிறீர்கள் என்றால்) அழுத்த வேண்டிய நேரம் வந்துவிட்டது, அதாவது திட்டத்தை இயக்கவும். கன்சோலில் நீங்கள் பார்ப்பது இதுதான்:

உன்னை பார்! நீங்கள் உங்கள் சொந்த விதிவிலக்கை உருவாக்கி அதை சிறிது சோதித்தீர்கள். இந்த சாதனைக்கு வாழ்த்துக்கள்! குறியீடு எவ்வாறு செயல்படுகிறது என்பதை நன்கு புரிந்துகொள்ள, அதைச் சிறிது பரிசோதிக்க பரிந்துரைக்கிறேன்.

மற்றொரு காசோலையைச் சேர்க்கவும் - எடுத்துக்காட்டாக, தொலைபேசி எண்ணில் எழுத்துக்கள் உள்ளதா என்பதைச் சரிபார்க்கவும். ஒருவேளை நீங்கள் அறிந்திருப்பதைப் போல, ஃபோன் எண்களை எளிதாக நினைவில் வைத்துக் கொள்ள அமெரிக்காவில் கடிதங்கள் அடிக்கடி பயன்படுத்தப்படுகின்றன, எ.கா. 1-800-MY-APPLE. உங்கள் காசோலையில் ஃபோன் எண்ணில் எண்கள் மட்டுமே உள்ளதா என்பதை உறுதிப்படுத்த முடியும்.

சரி, சரிபார்க்கப்பட்ட விதிவிலக்கை உருவாக்கியுள்ளோம். எல்லாம் நன்றாகவும் நன்றாகவும் இருக்கும், ஆனால் ...

நிரலாக்க சமூகம் இரண்டு முகாம்களாக பிரிக்கப்பட்டுள்ளது - சரிபார்க்கப்பட்ட விதிவிலக்குகளுக்கு ஆதரவாக இருப்பவர்கள் மற்றும் அவர்களை எதிர்ப்பவர்கள். இரு தரப்பும் வலுவான வாதங்களை முன்வைக்கின்றன. இரண்டுமே சிறந்த டெவலப்பர்களை உள்ளடக்கியது: ப்ரூஸ் எக்கல் சரிபார்க்கப்பட்ட விதிவிலக்குகளை விமர்சிக்கிறார், அதே நேரத்தில் ஜேம்ஸ் கோஸ்லிங் அவர்களைப் பாதுகாக்கிறார். இந்த விவகாரம் நிரந்தரமாக தீர்க்கப்படாது என்று தெரிகிறது. சரிபார்க்கப்பட்ட விதிவிலக்குகளைப் பயன்படுத்துவதன் முக்கிய தீமைகளைப் பார்ப்போம்.

சரிபார்க்கப்பட்ட விதிவிலக்குகளின் முக்கிய தீமை என்னவென்றால் , அவை கையாளப்பட வேண்டும். இங்கே எங்களிடம் இரண்டு விருப்பங்கள் உள்ளன: ஒன்று முயற்சி-பிடிப்பைப் பயன்படுத்தி அதைக் கையாளவும் , அல்லது, பல இடங்களில் அதே விதிவிலக்கைப் பயன்படுத்தினால், விதிவிலக்குகளை மேலே தூக்கி எறிந்து, அவற்றை உயர்நிலை வகுப்புகளில் செயலாக்கவும்.

மேலும், நாம் "பாய்லர் பிளேட்" குறியீட்டுடன் முடிவடையும், அதாவது அதிக இடத்தை எடுத்துக் கொள்ளும் குறியீடு, ஆனால் அதிக எடை தூக்கும் செயல்களைச் செய்யாது.

பல விதிவிலக்குகள் கையாளப்படுவதால், மிகப் பெரிய பயன்பாடுகளில் சிக்கல்கள் எழுகின்றன: உயர்மட்ட முறையில் வீசுதல்கள் பட்டியல் ஒரு டஜன் விதிவிலக்குகளைச் சேர்க்க எளிதாக வளரும்.

டெவலப்பர்கள் பொதுவாக இதை விரும்புவதில்லை, அதற்குப் பதிலாக ஒரு தந்திரத்தைத் தேர்வு செய்கிறார்கள்: அவர்கள் சரிபார்க்கப்பட்ட விதிவிலக்குகள் அனைத்தையும் ஒரு பொதுவான மூதாதையராக ஆக்குகிறார்கள் — 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 தொகுப்பிலிருந்து URL வகுப்பின் குடல்களை (குறியீடு) பார்க்கலாம் . நீங்கள் தெரிந்து கொள்ள விரும்பினால் என்னைப் பின்தொடரவும்!

URL வகுப்பில் உள்ள கட்டுமானங்களில் ஒன்று இங்கே :

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;
}
    

இந்த வரிகளை ஐடிஇயில் எழுதியவுடன் (நான் ஐடிஇஏவில் குறியிடுகிறேன், ஆனால் இது எக்லிப்ஸ் மற்றும் நெட்பீன்ஸில் கூட வேலை செய்யும்), இதைப் பார்ப்பீர்கள்:

இதன் பொருள், நாம் விதிவிலக்கைத் தூக்கி எறிய வேண்டும் அல்லது குறியீட்டை முயற்சி-பிடிப்புத் தொகுதியில் மடிக்க வேண்டும். இப்போதைக்கு, என்ன நடக்கிறது என்பதைக் காண இரண்டாவது விருப்பத்தைத் தேர்வுசெய்ய பரிந்துரைக்கிறேன்:

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

நீங்கள் பார்க்க முடியும் என, குறியீடு ஏற்கனவே வாய்மொழியாக உள்ளது. நாங்கள் அதை மேலே குறிப்பிட்டோம். சரிபார்க்கப்படாத விதிவிலக்குகளைப் பயன்படுத்துவதற்கான மிகத் தெளிவான காரணங்களில் இதுவும் ஒன்றாகும்.

ஜாவாவில் RuntimeExceptionஐ நீட்டிப்பதன் மூலம் சரிபார்க்கப்படாத விதிவிலக்கை உருவாக்கலாம் .

சரிபார்க்கப்படாத விதிவிலக்குகள் பிழை வகுப்பு அல்லது 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. விதிவிலக்குகள் என்று வரும்போது, ​​அவற்றை ஒரே நேரத்தில் பிடிப்பது தவறான நடைமுறை (என்னுடைய சக ஊழியர் கூறியது போல், "இது போகிமொன் அல்ல, இது ஜாவா"), எனவே பிடிப்பதைத் தவிர்க்கவும் (விதிவிலக்கு இ) அல்லது மோசமாக, கேட்ச் ( எறியக்கூடிய டி ) .

3. விதிவிலக்குகளை முடிந்தவரை விரைவாக எறியுங்கள். இது ஒரு நல்ல ஜாவா புரோகிராமிங் பயிற்சி. ஸ்பிரிங் போன்ற கட்டமைப்புகளை நீங்கள் படிக்கும்போது, ​​​​அவை "வேகமாக தோல்வியடையும்" கொள்கையைப் பின்பற்றுவதை நீங்கள் காண்பீர்கள். அதாவது, பிழையை விரைவாகக் கண்டுபிடிப்பதை சாத்தியமாக்கும் வகையில் அவை கூடிய விரைவில் "தோல்வியடைகின்றன". நிச்சயமாக, இது சில சிரமங்களைக் கொண்டுவருகிறது. ஆனால் இந்த அணுகுமுறை மிகவும் வலுவான குறியீட்டை உருவாக்க உதவுகிறது.

4. குறியீட்டின் பிற பகுதிகளை அழைக்கும்போது, ​​சில விதிவிலக்குகளைப் பெறுவது நல்லது. அழைக்கப்படும் குறியீடு பல விதிவிலக்குகளை எறிந்தால், அந்த விதிவிலக்குகளின் பெற்றோர் வகுப்பை மட்டும் பிடிப்பது மோசமான நிரலாக்க நடைமுறையாகும். எடுத்துக்காட்டாக, FileNotFoundException மற்றும் IOException ஐ வீசும் குறியீட்டை நீங்கள் அழைக்கிறீர்கள் . இந்தத் தொகுதியை அழைக்கும் உங்கள் குறியீட்டில், விதிவிலக்குகளைப் பிடிக்க ஒரு கேட்ச் என்பதற்குப் பதிலாக, விதிவிலக்குகள் ஒவ்வொன்றையும் பிடிக்க இரண்டு கேட்ச் பிளாக்குகளை எழுதுவது நல்லது .

5. பயனர்கள் மற்றும் பிழைத்திருத்தத்திற்கு நீங்கள் திறம்பட கையாளும் போது மட்டுமே விதிவிலக்குகளைப் பிடிக்கவும்.

6. உங்கள் சொந்த விதிவிலக்குகளை எழுத தயங்க வேண்டாம். நிச்சயமாக, ஜாவாவில் நிறைய ஆயத்தங்கள் உள்ளன, ஒவ்வொரு சந்தர்ப்பத்திற்கும் ஏதாவது, ஆனால் சில நேரங்களில் நீங்கள் இன்னும் உங்கள் சொந்த "சக்கரத்தை" கண்டுபிடிக்க வேண்டும். ஆனால் நீங்கள் ஏன் இதைச் செய்கிறீர்கள் என்பதை நீங்கள் தெளிவாகப் புரிந்து கொள்ள வேண்டும் மற்றும் நிலையான விதிவிலக்குகள் ஏற்கனவே உங்களுக்குத் தேவையானதைக் கொண்டிருக்கவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

7. உங்கள் சொந்த விதிவிலக்கு வகுப்புகளை உருவாக்கும்போது, ​​பெயரிடுவதில் கவனமாக இருங்கள்! வகுப்புகள், மாறிகள், முறைகள் மற்றும் தொகுப்புகளை சரியாக பெயரிடுவது மிகவும் முக்கியம் என்பதை நீங்கள் ஏற்கனவே அறிந்திருக்கலாம். விதிவிலக்குகள் விதிவிலக்கல்ல! :) எப்பொழுதும் விதிவிலக்கு என்ற வார்த்தையுடன் முடிக்கவும் , விதிவிலக்கின் பெயர் அது பிரதிபலிக்கும் பிழையின் வகையை தெளிவாக தெரிவிக்க வேண்டும். எடுத்துக்காட்டாக, FileNotFoundException .

8. உங்கள் விதிவிலக்குகளை ஆவணப்படுத்தவும். விதிவிலக்குகளுக்கு @throws Javadoc குறிச்சொல்லை எழுத பரிந்துரைக்கிறோம். உங்கள் குறியீடு எந்த வகையான இடைமுகங்களையும் வழங்கும் போது இது மிகவும் பயனுள்ளதாக இருக்கும். மேலும் உங்களின் சொந்தக் குறியீட்டைப் பின்னர் எளிதாகப் புரிந்துகொள்வதையும் நீங்கள் எளிதாகக் காணலாம். நீங்கள் என்ன நினைக்கிறீர்கள், MalformedURLexception என்பது எதைப் பற்றியது என்பதை எப்படி தீர்மானிக்க முடியும்? Javadoc இலிருந்து! ஆமாம், ஆவணங்களை எழுதும் எண்ணம் மிகவும் கவர்ச்சிகரமானதாக இல்லை, ஆனால் என்னை நம்புங்கள், ஆறு மாதங்களுக்குப் பிறகு உங்கள் சொந்த குறியீட்டிற்குத் திரும்பும்போது நீங்களே நன்றி சொல்வீர்கள்.

9. ஆதாரங்களை விடுங்கள் மற்றும் ஆதாரங்களுடன் முயற்சி செய்வதை புறக்கணிக்காதீர்கள் .

10. இங்கே ஒட்டுமொத்த சுருக்கம்: விதிவிலக்குகளை புத்திசாலித்தனமாக பயன்படுத்தவும். விதிவிலக்கை எறிவது வளங்களின் அடிப்படையில் மிகவும் "விலையுயர்ந்த" செயலாகும். பல சமயங்களில், விதிவிலக்குகளைத் தவிர்ப்பது எளிதாக இருக்கலாம், அதற்குப் பதிலாக ஒரு பூலியன் மாறியை திரும்பப் பெறலாம், அது ஒரு எளிய மற்றும் "குறைவான விலை" ஐப் பயன்படுத்தி, அறுவை சிகிச்சை வெற்றியடைந்ததா என்பதைச் சொல்லலாம் .

    பயன்பாட்டு தர்க்கத்தை விதிவிலக்குகளுடன் இணைக்க இது தூண்டுதலாக இருக்கலாம், அதை நீங்கள் தெளிவாக செய்யக்கூடாது. கட்டுரையின் ஆரம்பத்தில் நாங்கள் கூறியது போல், விதிவிலக்குகள் விதிவிலக்கான சூழ்நிலைகள், எதிர்பார்க்கப்படாதவை, அவற்றைத் தடுக்க பல்வேறு கருவிகள் உள்ளன. குறிப்பாக, ஒரு NullPointerException ஐத் தடுக்க விருப்பத்தேர்வு உள்ளது , அல்லது IOException ஐத் தடுக்க Scanner.hasNext போன்றவை உள்ளது , அதை read() முறை தூக்கி எறியலாம்.