आपले स्वतःचे अपवाद तयार करणे

मला वाटते की तुम्ही कदाचित अशी परिस्थिती अनुभवली असेल जिथे तुम्ही कोड चालवता आणि 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;
}
    

तुम्ही IDE मध्ये या ओळी लिहिताच (मी IDEA मध्ये कोडिंग करत आहे, परंतु हे Eclipse आणि NetBeans मध्ये देखील कार्य करते), तुम्हाला हे दिसेल:

याचा अर्थ असा की आम्हाला एकतर अपवाद फेकणे आवश्यक आहे किंवा कोड ट्राय-कॅच ब्लॉकमध्ये गुंडाळणे आवश्यक आहे. आत्तासाठी, मी काय घडत आहे याची कल्पना करण्यासाठी दुसरा पर्याय निवडण्याचा सल्ला देतो:

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

तुम्ही बघू शकता, कोड आधीच ऐवजी शब्दशः आहे. आणि आम्ही वर उल्लेख केला आहे. अनचेक अपवाद वापरण्याचे हे सर्वात स्पष्ट कारणांपैकी एक आहे.

Java मध्ये 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);
   }
}
    

लक्षात घ्या की आम्ही वेगवेगळ्या उद्देशांसाठी अनेक कन्स्ट्रक्टर बनवले आहेत. हे आम्हाला आमच्या अपवादाला अधिक क्षमता देऊ देते. उदाहरणार्थ, आम्ही ते करू शकतो जेणेकरून अपवाद आम्हाला त्रुटी कोड देईल. सुरुवातीला, आमच्या एरर कोडचे प्रतिनिधित्व करण्यासाठी एक एनम बनवूया:

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

}
    

तुम्ही ज्या प्रकारे ऑब्जेक्ट्ससह कार्य करता त्याच प्रकारे तुम्ही अपवादांसह कार्य करू शकता. अर्थात, मला खात्री आहे की जावा मधील प्रत्येक गोष्ट एक वस्तू आहे हे तुम्हाला आधीच माहित आहे.

आणि आम्ही काय केले ते पहा. प्रथम, आम्ही पद्धत बदलली, जी आता फेकत नाही, परंतु त्याऐवजी इनपुट पॅरामीटरवर अवलंबून फक्त एक अपवाद तयार करते. पुढे, स्विच-केस स्टेटमेंट वापरून, आम्ही इच्छित त्रुटी कोड आणि संदेशासह अपवाद व्युत्पन्न करतो. आणि मुख्य पद्धतीमध्ये, आम्हाला तयार केलेला अपवाद मिळतो, एरर कोड मिळतो आणि तो फेकतो.

चला हे चालवू आणि कन्सोलवर काय मिळते ते पाहू:

पहा - आम्ही अपवादातून मिळालेला त्रुटी कोड मुद्रित केला आणि नंतर अपवाद स्वतःच फेकून दिला. इतकेच काय, अपवाद नेमका कुठे टाकला गेला याचा मागोवाही आपण घेऊ शकतो. आवश्यकतेनुसार, तुम्ही संदेशामध्ये सर्व संबंधित माहिती जोडू शकता, अतिरिक्त त्रुटी कोड तयार करू शकता आणि तुमच्या अपवादांमध्ये नवीन वैशिष्ट्ये जोडू शकता.

बरं, तुम्हाला त्याबद्दल काय वाटतं? मला आशा आहे की आपल्यासाठी सर्वकाही कार्य केले आहे!

सर्वसाधारणपणे, अपवाद हा एक विस्तृत विषय आहे आणि स्पष्ट नाही. त्यावरून आणखी बरेच वाद होतील. उदाहरणार्थ, फक्त Java ने अपवाद तपासले आहेत. सर्वात लोकप्रिय भाषांपैकी, मी त्यांचा वापर करणारी एकही पाहिली नाही.

ब्रूस एकेलने त्याच्या "थिंकिंग इन जावा" या पुस्तकाच्या 12 व्या अध्यायात अपवादांबद्दल खूप चांगले लिहिले आहे — मी शिफारस करतो की तुम्ही ते वाचा! हॉर्स्टमनच्या "कोअर जावा" च्या पहिल्या खंडावर देखील एक नजर टाका — यात अध्याय 7 मध्ये खूप मनोरंजक गोष्टी आहेत.

एक छोटासा सारांश

1. लॉगमध्ये सर्वकाही लिहा! फेकलेल्या अपवादांमध्ये लॉग इन करा. हे सहसा डीबगिंगमध्ये खूप मदत करेल आणि तुम्हाला काय झाले हे समजण्यास अनुमती देईल. कॅच ब्लॉक रिकामा सोडू नका , अन्यथा तो अपवाद फक्त "गिळला" जाईल आणि समस्या शोधण्यात मदत करण्यासाठी तुमच्याकडे कोणतीही माहिती नसेल.

2. अपवादांचा विचार केल्यास, त्यांना एकाच वेळी पकडणे ही वाईट प्रथा आहे (माझ्या एका सहकाऱ्याने म्हटल्याप्रमाणे, "हा पोकेमॉन नाही, तो जावा आहे"), म्हणून पकडणे टाळा (अपवाद e) किंवा वाईट म्हणजे पकडणे ( फेकण्यायोग्य t ) .

3. शक्य तितक्या लवकर अपवाद फेकून द्या. हा जावा प्रोग्रामिंगचा चांगला सराव आहे. जेव्हा तुम्ही स्प्रिंग सारख्या फ्रेमवर्कचा अभ्यास करता तेव्हा तुम्हाला दिसेल की ते "फेल फास्ट" तत्त्वाचे पालन करतात. म्हणजेच, त्रुटी लवकर शोधणे शक्य करण्यासाठी ते शक्य तितक्या लवकर "अयशस्वी" होतात. अर्थात, यामुळे काही गैरसोयी होतात. परंतु हा दृष्टिकोन अधिक मजबूत कोड तयार करण्यात मदत करतो.

4. कोडच्या इतर भागांना कॉल करताना, काही अपवाद पकडणे चांगले. म्हटल्या जाणार्‍या कोडने एकाधिक अपवाद टाकल्यास, फक्त त्या अपवादांचा मूळ वर्ग पकडणे हा प्रोग्रामिंग सराव खराब आहे. उदाहरणार्थ, तुम्ही FileNotFoundException आणि IOException फेकणारा कोड कॉल करा . या मॉड्यूलला कॉल करणार्‍या तुमच्या कोडमध्ये, अपवाद पकडण्यासाठी एकच कॅच ऐवजी प्रत्येक अपवाद पकडण्यासाठी दोन कॅच ब्लॉक लिहिणे चांगले .

5. जेव्हा तुम्ही वापरकर्त्यांसाठी आणि डीबगिंगसाठी त्यांना प्रभावीपणे हाताळू शकता तेव्हाच अपवाद पकडा.

6. तुमचे स्वतःचे अपवाद लिहिण्यास अजिबात संकोच करू नका. नक्कीच, जावामध्ये बरेच रेडीमेड आहेत, प्रत्येक प्रसंगासाठी काहीतरी, परंतु काहीवेळा आपल्याला आपले स्वतःचे "चाक" शोधण्याची आवश्यकता आहे. परंतु तुम्ही हे का करत आहात हे तुम्ही स्पष्टपणे समजून घेतले पाहिजे आणि अपवादांच्या मानक संचामध्ये तुम्हाला जे हवे आहे ते आधीपासूनच नाही याची खात्री करा.

7. तुम्ही तुमचे स्वतःचे अपवाद वर्ग तयार करता तेव्हा, नामकरणाची काळजी घ्या! तुम्हाला कदाचित आधीच माहित असेल की वर्ग, व्हेरिएबल्स, पद्धती आणि पॅकेजेस योग्यरित्या नाव देणे अत्यंत महत्वाचे आहे. अपवाद काही अपवाद नाहीत! :) नेहमी अपवाद या शब्दाने समाप्त करा , आणि अपवादाच्या नावाने तो कोणत्या त्रुटीचा प्रकार दर्शवतो हे स्पष्टपणे व्यक्त केले पाहिजे. उदाहरणार्थ, FileNotFoundException .

8. तुमचे अपवाद दस्तऐवजीकरण करा. आम्ही अपवादांसाठी @throws Javadoc टॅग लिहिण्याची शिफारस करतो. जेव्हा तुमचा कोड कोणत्याही प्रकारचे इंटरफेस प्रदान करतो तेव्हा हे विशेषतः उपयुक्त ठरेल. आणि तुम्हाला तुमचा स्वतःचा कोड नंतर समजून घेणे देखील सोपे जाईल. तुम्हाला काय वाटते, MalformedURLException कशाबद्दल आहे हे तुम्ही कसे ठरवू शकता? Javadoc कडून! होय, दस्तऐवज लिहिण्याचा विचार फारसा आकर्षक नाही, परंतु माझ्यावर विश्वास ठेवा, सहा महिन्यांनंतर तुम्ही तुमच्या स्वतःच्या कोडवर परत आल्यावर तुमचे आभार मानाल.

9. रिसोर्सेस सोडा आणि रिसोर्सेसच्या सहाय्याने प्रयत्न करण्याकडे दुर्लक्ष करू नका .

10. येथे एकूण सारांश आहे: अपवाद हुशारीने वापरा. अपवाद फेकणे हे संसाधनांच्या दृष्टीने बऱ्यापैकी "महाग" ऑपरेशन आहे. बर्‍याच प्रकरणांमध्ये, अपवाद फेकणे टाळणे सोपे असू शकते आणि त्याऐवजी, एक साधे आणि "कमी खर्चिक" if- else वापरून ऑपरेशन यशस्वी झाले की नाही हे एक बुलियन व्हेरिएबल परत करणे सोपे असू शकते .

    अनुप्रयोग तर्काला अपवादांशी जोडणे देखील मोहक असू शकते, जे तुम्ही स्पष्टपणे करू नये. आम्ही लेखाच्या सुरुवातीला म्हटल्याप्रमाणे, अपवाद अपवादात्मक परिस्थितीसाठी आहेत, अपेक्षित नाहीत आणि त्यांना प्रतिबंध करण्यासाठी विविध साधने आहेत. विशेषतः, IOException प्रतिबंधित करण्यासाठी NullPointerException , किंवा Scanner.hasNext आणि यासारखे पर्यायी आहेत , जे read() पद्धत टाकू शकते.