क्या नई RuntimeException को अगम्य कोड में फेंकना एक बुरी शैली है?

Question

मुझे कुछ कुशल डेवलपर्स द्वारा कुछ समय पहले लिखे गए एप्लिकेशन को बनाए रखने के लिए सौंपा गया था। मुझे यह कोड आया:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
        try {
            return translate(mailManagementService.retrieveUserMailConfiguration(id));
        } catch (Exception e) {
            rethrow(e);
        }
        throw new RuntimeException("cannot reach here");
    }

मुझे उत्सुकता है अगर फेंकना RuntimeException("cannot reach here")उचित है। मुझे शायद यह जानकर कुछ याद आ रहा है कि कोड का यह टुकड़ा अधिक अनुभवी सहकर्मी से आता है।
संपादित करें: यहाँ पुनर्विचार निकाय है जिसे कुछ उत्तर संदर्भित किए गए हैं। मैंने इस प्रश्न में इसे महत्वपूर्ण नहीं समझा।

private void rethrow(Exception e) throws MailException {
        if (e instanceof InvalidDataException) {
            InvalidDataException ex = (InvalidDataException) e;
            rethrow(ex);
        }
        if (e instanceof EntityAlreadyExistsException) {
            EntityAlreadyExistsException ex = (EntityAlreadyExistsException) e;
            rethrow(ex);
        }
        if (e instanceof EntityNotFoundException) {
            EntityNotFoundException ex = (EntityNotFoundException) e;
            rethrow(ex);
        }
        if (e instanceof NoPermissionException) {
            NoPermissionException ex = (NoPermissionException) e;
            rethrow(ex);
        }
        if (e instanceof ServiceUnavailableException) {
            ServiceUnavailableException ex = (ServiceUnavailableException) e;
            rethrow(ex);
        }
        LOG.error("internal error, original exception", e);
        throw new MailUnexpectedException();
    }


private void rethrow(ServiceUnavailableException e) throws
            MailServiceUnavailableException {
        throw new MailServiceUnavailableException();
    }

private void rethrow(NoPermissionException e) throws PersonNotAuthorizedException {
    throw new PersonNotAuthorizedException();
}

private void rethrow(InvalidDataException e) throws
        MailInvalidIdException, MailLoginNotAvailableException,
        MailInvalidLoginException, MailInvalidPasswordException,
        MailInvalidEmailException {
    switch (e.getDetail()) {
        case ID_INVALID:
            throw new MailInvalidIdException();
        case LOGIN_INVALID:
            throw new MailInvalidLoginException();
        case LOGIN_NOT_ALLOWED:
            throw new MailLoginNotAvailableException();
        case PASSWORD_INVALID:
            throw new MailInvalidPasswordException();
        case EMAIL_INVALID:
            throw new MailInvalidEmailException();
    }
}

private void rethrow(EntityAlreadyExistsException e)
        throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
    switch (e.getDetail()) {
        case LOGIN_ALREADY_TAKEN:
            throw new MailLoginNotAvailableException();
        case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
            throw new MailEmailAddressAlreadyForwardedToException();
    }
}

private void rethrow(EntityNotFoundException e) throws
        MailAccountNotCreatedException,
        MailAliasNotCreatedException {
    switch (e.getDetail()) {
        case ACCOUNT_NOT_FOUND:
            throw new MailAccountNotCreatedException();
        case ALIAS_NOT_FOUND:
            throw new MailAliasNotCreatedException();
    }
}

Comments

यह तकनीकी रूप से उपलब्ध है, अगर rethrowवास्तव throwमें अपवाद नहीं है। (जो किसी दिन हो सकता है, अगर कार्यान्वयन बदल जाए)

— njzk2

एक तरफ के रूप में, एक AssertionError RuntimeException की तुलना में एक बेहतर रूप से बेहतर विकल्प हो सकता है।

— JvR

अंतिम फेंक बेमानी है। यदि आप खोजबीन या अन्य स्थिर विश्लेषण उपकरण सक्षम करते हैं, तो यह हटाने के लिए इस प्रकार की रेखाओं को चिह्नित करेगा।

— बॉन अमी

अब जब मैं बाकी कोड देख रहा हूं, तो मैं सोच रहा हूं कि शायद आपको "अधिक कुशल डेवलपर्स" को "अधिक वरिष्ठ डेवलपर्स" में बदलना चाहिए । कोड की समीक्षा यह बताने में खुशी होगी कि क्यों।

— JvR

मैंने अपवादों को भयानक क्यों है के काल्पनिक उदाहरण बनाने की कोशिश की है। लेकिन कुछ भी मैंने कभी नहीं किया है कि यह एक मोमबत्ती रखती है।

— पॉल ड्रेपर

Answer 1

सबसे पहले, आपके सवाल का जवाब देने और हमें यह दिखाने के लिए धन्यवाद rethrow। तो, वास्तव में, यह क्या करता है अपवादों के गुणों के साथ और अधिक बारीक-दाने वाले वर्गों में परिवर्तित हो रहा है। इस पर और बाद में।

चूंकि मैंने वास्तव में मुख्य प्रश्न का मूल रूप से उत्तर नहीं दिया था, इसलिए यह यहां जाता है: हां, यह आमतौर पर अस्वाभाविक कोड में रनटाइम अपवादों को फेंकने के लिए खराब शैली है; बेहतर होगा कि आप समस्या से बचने के लिए, या बेहतर उपयोग करें। जैसा कि पहले ही बताया जा चुका है, यहां संकलक यह सुनिश्चित नहीं कर सकता है कि कोड कभी भी try/catchब्लॉक से बाहर नहीं जाए । आप अपने कोड का लाभ उठाकर लाभ उठा सकते हैं कि ...

त्रुटियां मूल्य हैं

^{(अप्रत्याशित रूप से, यह जाना- पहचाना है )}

आइए एक सरल उदाहरण का उपयोग करें, जिसे मैंने आपके संपादन से पहले उपयोग किया था: इसलिए कल्पना करें कि आप कुछ लॉग कर रहे हैं और कोनराड के उत्तर की तरह एक आवरण अपवाद का निर्माण कर रहे हैं । चलो बुलावा आया logAndWrap।

इसके अपवाद को साइड-इफेक्ट के रूप में फेंकने के बजाय logAndWrap, आप इसे साइड-इफ़ेक्ट के रूप में अपना काम करने दे सकते हैं और इसे एक अपवाद (कम से कम, इनपुट में दिया गया) वापस कर सकते हैं। आपको जेनरिक का उपयोग करने की आवश्यकता नहीं है, बस बुनियादी कार्य:

private Exception logAndWrap(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    return new CustomWrapperException(exception);
}

फिर, आप throwसमझदारी से, और आपका कंपाइलर खुश है:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     throw logAndWrap(e);
}

क्या होगा अगर आप भूल जाते हैं throw?

जैसा कि जेओ 23 की टिप्पणी में बताया गया है , यह सुनिश्चित करने के लिए एक रक्षात्मक प्रोग्रामिंग तरीका है कि अपवाद हमेशा फेंका जाता है throw new CustomWrapperException(exception), जिसमें अंत में गुवाहाटीlogAndWrap द्वारा किया जाता है । इस तरह, आप जानते हैं कि अपवाद को फेंक दिया जाएगा, और आपका प्रकार विश्लेषक खुश है। हालांकि, आपके कस्टम अपवादों को अनियंत्रित अपवादों की आवश्यकता होती है, जो हमेशा संभव नहीं होता है। इसके अलावा, मैं एक विकासकर्ता के जोखिम को बहुत कम लिखने के लिए गायब होने का जोखिम उठाता हूँ : डेवलपर को इसे भूल जाना चाहिए और आस-पास की विधि को कुछ भी वापस नहीं करना चाहिए, अन्यथा कंपाइलर एक लापता रिटर्न का पता लगाएगा। यह प्रकार प्रणाली से लड़ने का एक दिलचस्प तरीका है, और यह काम करता है, हालांकि।throw

Rethrow

वास्तविक rethrowको एक फ़ंक्शन के रूप में भी लिखा जा सकता है, लेकिन मुझे इसके वर्तमान कार्यान्वयन में समस्याएं हैं:

• जैसे कई बेकार जातियां हैं जातियां वास्तव में आवश्यक हैं (टिप्पणियां देखें):

  if (e instanceof ServiceUnavailableException) {
      ServiceUnavailableException ex = (ServiceUnavailableException) e;
      rethrow(ex);
  }

• नए अपवादों को फेंकने / वापस करने पर, पुराने को छोड़ दिया जाता है; निम्नलिखित कोड में, MailLoginNotAvailableExceptionमुझे यह जानने की अनुमति नहीं देता है कि कौन सा लॉगिन उपलब्ध नहीं है, जो असुविधाजनक है; इसके अलावा, स्टैकट्रैक अधूरे होंगे:

  private void rethrow(EntityAlreadyExistsException e)
      throws MailLoginNotAvailableException, MailEmailAddressAlreadyForwardedToException {
      switch (e.getDetail()) {
          case LOGIN_ALREADY_TAKEN:
              throw new MailLoginNotAvailableException();
          case EMAIL_ADDRESS_ALREADY_FORWARDED_TO:
              throw new MailEmailAddressAlreadyForwardedToException();
      }
  }

• मूल कोड उन विशिष्ट अपवादों को पहली जगह पर क्यों नहीं फेंकता है? मुझे संदेह है कि rethrowएक (मेलिंग) सबसिस्टम और बिज़ीनेस लॉजिक के बीच एक संगतता परत के रूप में उपयोग किया जाता है (हो सकता है कि इरादा कार्यान्वयन के विवरण को छिपाने के लिए हो, जैसे कि कस्टम अपवाद द्वारा उन्हें हटाकर फेंक दिया गया हो)। यहां तक ​​कि अगर मैं सहमत हूं कि कैच-फ्री कोड होना बेहतर होगा, जैसा कि पीट बेकर के जवाब में सुझाया गया है , तो मुझे नहीं लगता कि आपके पास प्रमुख रिफैक्टोरिंग के बिना कोड catchऔर rethrowकोड को हटाने का अवसर होगा ।

Comments

जातियां बेकार नहीं हैं। वे आवश्यक हैं, क्योंकि तर्क प्रकार के आधार पर कोई गतिशील प्रेषण नहीं है। सही विधि को कॉल करने के लिए संकलन समय पर तर्क प्रकार ज्ञात होना चाहिए।

— २३

अपनी logAndWrapपद्धति में आप इसे वापस करने के बजाय अपवाद को फेंक सकते हैं, लेकिन रिटर्न प्रकार को बनाए रख सकते हैं (Runtime)Exception। इस तरह से कैच ब्लॉक आपके द्वारा लिखे गए तरीके (अनुपयोगी कोड में बिना थ्रो) के रह सकता है। लेकिन इसका अतिरिक्त फायदा है कि आप इसे नहीं भूल सकते throw। यदि आप अपवाद वापस करते हैं और फेंक को भूल जाते हैं तो यह अपवाद चुपचाप निगल लिया जाएगा। एक वापसी प्रकार RuntimeException होने पर फेंकने से कंपाइलर खुश होंगे जबकि इन त्रुटियों से भी बचेंगे। इसी तरह अमरूद Throwables.propagateको लागू किया जाता है।

— 23

@ जो23 स्टेटिक डिस्पैच के बारे में स्पष्टीकरण के लिए धन्यवाद। फ़ंक्शन के अंदर अपवादों को फेंकने के बारे में: क्या आपका मतलब है कि आप जिस संभावित त्रुटि का वर्णन कर रहे हैं वह एक कैच ब्लॉक है जो कॉल logAndWrapकरता है लेकिन लौटे अपवाद के साथ कुछ भी नहीं करता है? यह तो दिलचस्प है। किसी फ़ंक्शन के अंदर जो किसी मान को वापस करना चाहिए, संकलक ध्यान देगा कि कोई ऐसा मार्ग है जिसमें कोई मान नहीं दिया जा रहा है, लेकिन यह उन तरीकों के लिए उपयोगी है जो कुछ भी वापस नहीं करते हैं। एक बार फिर धन्यवाद।

— coredump

ठीक वैसा ही जैसा मैं करता हूं। और बस फिर से बात पर जोर देने के लिए: यह ऐसा कुछ नहीं है जिसके साथ मैं आया था और इसका श्रेय लेता हूं, लेकिन अमरूद स्रोत से चमकता हुआ।

— 23

@ जो 23 मैंने लाइब्रेरी का एक स्पष्ट संदर्भ जोड़ा

— कोरडंप

Answer 2

यह rethrow(e);फ़ंक्शन उस सिद्धांत का उल्लंघन करता है जो कहता है कि सामान्य परिस्थितियों में, एक फ़ंक्शन वापस आ जाएगा, जबकि असाधारण परिस्थितियों में, एक फ़ंक्शन अपवाद को फेंक देगा। यह फ़ंक्शन सामान्य परिस्थितियों में अपवाद को फेंककर इस सिद्धांत का उल्लंघन करता है। यही सब भ्रम का स्रोत है।

कंपाइलर मानता है कि यह फ़ंक्शन सामान्य परिस्थितियों में वापस आ जाएगा, इसलिए जहां तक ​​कंपाइलर बता सकता है, निष्पादन retrieveUserMailConfigurationफ़ंक्शन के अंत तक पहुंच सकता है , जिस बिंदु पर यह एक returnबयान नहीं होने के लिए एक त्रुटि है । RuntimeExceptionफेंका वहाँ संकलक की इस चिंता को कम करने के लिए माना जाता है, लेकिन यह यह कर के एक नहीं बल्कि भद्दा तरीका है। function must return a valueत्रुटि को रोकने का एक और तरीका एक return null; //to keep the compiler happyबयान जोड़ना है , लेकिन यह मेरी राय में समान रूप से स्पष्ट है।

इसलिए, व्यक्तिगत रूप से, मैं इसे प्रतिस्थापित करूंगा:

rethrow(e);

इसके साथ:

report(e); 
throw e;

या, बेहतर अभी तक, (जैसा कि coredump ने सुझाव दिया है ), इसके साथ:

throw reportAndTransform(e);

इस प्रकार, नियंत्रण के प्रवाह को संकलक के लिए स्पष्ट किया जाएगा, इसलिए आपका फाइनल throw new RuntimeException("cannot reach here");न केवल निरर्थक हो जाएगा, बल्कि वास्तव में भी ऐसा नहीं होगा, क्योंकि यह संकलक द्वारा अगम्य कोड के रूप में चिह्नित किया जाएगा।

यह सबसे बदसूरत और वास्तव में भी इस बदसूरत स्थिति से बाहर निकलने का सबसे सरल तरीका है।

Comments

-1 फ़ंक्शन को दो कथनों में विभाजित करने का सुझाव देना खराब प्रतिलिपि / चिपकाने के कारण प्रोग्रामिंग त्रुटियों का परिचय दे सकता है; मैं भी थोड़ा तथ्य यह है कि आप अपने प्रश्न का सुझाव देने संपादित के बारे में चिंतित हूँ throw reportAndTransform(e)एक मिनट की जोड़ी के बाद मैं अपने खुद के उत्तर पोस्ट। हो सकता है कि आपने इसे स्वतंत्र रूप से प्रश्न के रूप में संशोधित किया हो, और अगर ऐसा है, तो मैं पहले से माफी मांगता हूं, लेकिन अन्यथा, थोड़ा सा क्रेडिट देना कुछ लोगों द्वारा आमतौर पर किया जाता है।

— coredump

@ कोर्डम्प मैं वास्तव में आपके सुझाव को पढ़ता था, और मैंने एक और उत्तर भी पढ़ा, जो इस सुझाव को आप तक पहुंचाता है, और मुझे याद आया कि मैंने वास्तव में अतीत में इस तरह के निर्माण को ठीक से नियोजित किया है, इसलिए मैंने इसे अपने उत्तर में शामिल करने का निर्णय लिया। मैंने सोचा था कि यह इतना महत्वपूर्ण नहीं है क्योंकि इसमें एक अटेंशन शामिल है, क्योंकि हम यहां एक मूल विचार के बारे में बात नहीं कर रहे हैं, लेकिन अगर आप इसके साथ समस्या उठाते हैं, तो मैं आपको उत्तेजित नहीं करना चाहता, इसलिए अटेंशन अब है। एक लिंक के साथ पूरा करें। चीयर्स।

— माइक नाकिस

ऐसा नहीं है कि मेरे पास इस निर्माण के लिए पेटेंट है, जो काफी सामान्य है; लेकिन कल्पना कीजिए कि आप एक उत्तर लिखते हैं और लंबे समय के बाद नहीं, यह एक दूसरे द्वारा "आत्मसात" है। तो एट्रिब्यूशन की बहुत सराहना की जाती है। धन्यवाद।

— coredump

वहाँ एक समारोह है कि वापस नहीं करता है के साथ प्रति गलत कुछ भी नहीं है। यह हर समय होता है, उदाहरण के लिए, रीयल-टाइम सिस्टम में। अंतिम समस्या जावा में एक दोष है कि भाषा विश्लेषण करती है और भाषाओं की शुद्धता की अवधारणा को लागू करती है और फिर भी भाषा किसी भी तरह से एनोटेटिंग के लिए एक तंत्र प्रदान नहीं करती है कि एक फ़ंक्शन वापस नहीं आता है। हालांकि, ऐसे डिज़ाइन पैटर्न हैं जो इसके आस-पास मिलते हैं जैसे कि throw reportAndTransform(e)। कई डिज़ाइन पैटर्न पैच हैं जो भाषा सुविधाएँ गायब हैं। यह उनमें से एक है।

— डेविड हैमेन

दूसरी ओर, कई आधुनिक भाषाएँ पर्याप्त जटिल हैं। हर डिज़ाइन पैटर्न को एक कोर लैंग्वेज फीचर में बदलना उन्हें और भी आगे बढ़ाएगा। यह एक डिज़ाइन पैटर्न का एक अच्छा उदाहरण है जो मूल भाषा में नहीं है। जैसा कि लिखा गया है, यह केवल संकलक द्वारा ही नहीं, बल्कि कई अन्य उपकरणों द्वारा भी समझा जाता है जिन्हें कोड को पार्स करना है।

— MSalters

Answer 3

throwशायद "विधि एक मान लौटाना चाहिए" चारों ओर पाने के लिए त्रुटि है कि अन्यथा घटित होता जोड़ा गया है - जावा डेटा प्रवाह विश्लेषक स्मार्ट समझने की है कि कोई भी पर्याप्त है returnएक के बाद आवश्यक है throw, लेकिन नहीं अपने कस्टम के बाद rethrow()विधि, और कोई है @NoReturnएनोटेशन आप इसे ठीक करने के लिए उपयोग कर सकते हैं।

फिर भी, अगम्य कोड में एक नया अपवाद बनाना अतिरेक लगता है। मैं बस लिखूंगा return null, यह जानते हुए कि यह वास्तव में कभी नहीं होता है।

Comments

तुम सही हो। मैंने जाँच की कि क्या होगा यदि मैं throw new...लाइन में टिप्पणी करता हूँ और यह बिना विवरण के बयान के बारे में शिकायत करता है। क्या यह खराब प्रोग्रामिंग है? क्या अनुपलब्ध रिटर्न स्टेटमेंट को प्रतिस्थापित करने के बारे में कोई सम्मेलन है? मैं अधिक इनपुट को प्रोत्साहित करने के लिए कुछ समय के लिए अनुत्तरित इस प्रश्न को छोड़ दूंगा। फिर भी आपके उत्तर के लिए धन्यवाद।

— सोक पोमरंकज़ोवे

@SokPomaranczowy हाँ, यह खराब प्रोग्रामिंग है। यह rethrow()विधि इस तथ्य catchको छिपाती है कि अपवाद को फिर से पढ़ना है। मैं ऐसा कुछ करने से बचूंगा। इसके अलावा, rethrow()वास्तव में , वास्तव में उस अपवाद को फिर से उखाड़ फेंकने में विफल हो सकता है, जिस स्थिति में कुछ और होता है।

— रॉस पैटरसन

कृपया अपवाद को प्रतिस्थापित न करें return null। अपवाद के साथ, यदि भविष्य में कोई व्यक्ति कोड को तोड़ता है तो अंतिम पंक्ति कुछ कैसे पहुंच योग्य हो जाती है, यह तुरंत स्पष्ट हो जाएगा जब अपवाद फेंक दिया जाता है। यदि आप इसके बजाय return null, अब आपके पास nullअपने आवेदन में एक मूल्य है जो अपेक्षित नहीं था। कौन जानता है कि आवेदन में कहां NullPointerExceptionउत्पन्न होगा? जब तक आप भाग्यशाली नहीं होते हैं और इस फ़ंक्शन को कॉल करने के बाद यह मध्यस्थता है, वास्तविक समस्या को ट्रैक करना बहुत कठिन होगा।

— अपहोल्समलर

@MatthewRead कोड का निष्पादन अनुपलब्ध होने का इरादा एक गंभीर बग है, बग return nullको मुखौटा करने की काफी संभावना है क्योंकि आप अन्य मामलों को भेद नहीं कर सकते हैं जहां यह nullइस बग से वापस आता है।

— कोडइन्चोअस

इसके अलावा, यदि फ़ंक्शन कुछ परिस्थितियों में पहले से ही अशक्त हो जाता है, और आप इस परिस्थिति में भी अशक्त रिटर्न का उपयोग करते हैं, तो उपयोगकर्ताओं के पास अब दो संभावित परिदृश्य हैं जब वे अशक्त रिटर्न प्राप्त कर सकते हैं। कभी-कभी यह कोई मायने नहीं रखता है, क्योंकि अशक्त वापसी का पहले से ही मतलब है "कोई वस्तु नहीं है और मैं निर्दिष्ट नहीं कर रहा हूं", इसलिए एक और संभावित कारण को जोड़ना क्योंकि थोड़ा अंतर है। लेकिन अक्सर अस्पष्टता को जोड़ना बुरा होता है, और यह निश्चित रूप से इसका मतलब है कि कीड़े को शुरू में "कुछ परिस्थितियों" की तरह "तुरंत टूट गया" की तरह देखा जाएगा। जल्दी असफल हो गए।

— स्टीव जेसोप

Answer 4

The

throw new RuntimeException("cannot reach here");

बयान से यह स्पष्ट हो जाता है कि एक व्यक्ति कोड को पढ़ रहा है जो कि चल रहा है, इसलिए यह बहुत बेहतर है और फिर उदाहरण के लिए वापस लौटना। यदि कोड को अप्रत्याशित तरीके से बदल दिया जाए तो यह डिबग करना भी आसान बना देता है।

हालाँकि rethrow(e)सिर्फ गलत लगता है! इसलिए आपके मामले में मुझे लगता है कि कोड को फिर से भरना एक बेहतर विकल्प है। अपने कोड को छाँटने के तरीकों के लिए अन्य उत्तर (मुझे coredump का सर्वश्रेष्ठ पसंद है) देखें।

Answer 5

मुझे नहीं पता कि क्या कोई सम्मेलन है।

किसी भी तरह, एक और चाल ऐसा करना होगा:

private <T> T rethrow(Exception exception) {
    // or whatever it actually does
    Log.e("Ouch! " + exception.getMessage());
    throw new CustomWrapperException(exception);
}

इसके लिए अनुमति देना:

try {
     return translate(mailManagementService.retrieveUserMailConfiguration(id));
} catch (Exception e) {
     return rethrow(e);
}

और RuntimeExceptionअब किसी कृत्रिम की जरूरत नहीं है। भले ही rethrowवास्तव में कभी भी कोई मूल्य वापस नहीं आता है, लेकिन यह अब संकलक के लिए पर्याप्त है।

यह सिद्धांत (विधि हस्ताक्षर) में एक मूल्य लौटाता है, और फिर इसे वास्तव में ऐसा करने से छूट मिलती है क्योंकि यह इसके बजाय एक अपवाद को फेंकता है।

हाँ, यह अजीब लग सकता है, लेकिन फिर फिर से - एक प्रेत फेंकना RuntimeException, या ऐसे नल को वापस करना जो इस दुनिया में कभी नहीं दिखाई देंगे - यह वास्तव में सौंदर्य की बात भी नहीं है।

पठनीयता के लिए प्रयास करते हुए, आप नाम बदल सकते हैं rethrowऔर कुछ इस तरह कर सकते हैं:

} catch (Exception e) {
     return nothingJustRethrow(e);
}

Answer 6

यदि आप tryब्लॉक को पूरी तरह से हटा देते हैं तो आपको rethrowया की आवश्यकता नहीं है throw। यह कोड मूल के समान कार्य करता है:

public Configuration retrieveUserMailConfiguration(Long id) throws MailException {
    return translate(mailManagementService.retrieveUserMailConfiguration(id));
}

तथ्य यह है कि यह अधिक अनुभवी डेवलपर्स से आता है मूर्ख मत करो। यह कोड रोट है, और यह हर समय होता है। बस इसे ठीक करो।

संपादित करें: मैंने rethrow(e)केवल अपवाद को फिर से फेंकने के रूप में गलत पढ़ा e। यदि वह rethrowविधि वास्तव में अपवाद को फिर से फेंकने के अलावा कुछ करती है, तो इससे छुटकारा पाने से इस पद्धति का शब्दार्थ बदल जाता है।

Comments

लोग विश्वास करते रहेंगे कि वाइल्डकार्ड कैच करता है जो कुछ भी नहीं संभालते हैं वास्तव में अपवाद हैंडलर हैं। आपका संस्करण उस अवहेलना की अवहेलना करता है जिसे संभालने का बहाना करके वह गलत नहीं हो सकता। पुनः प्राप्त करने वाले का कॉल करने वाला MailConfiguration () कुछ वापस पाने की उम्मीद करता है। यदि वह फ़ंक्शन कुछ उचित नहीं दे सकता है, तो उसे तेज़ और ज़ोर से विफल होना चाहिए। यह ऐसा है जैसे अन्य जवाबों में कोई समस्या नहीं देखी गई, catch(Exception)जिसके साथ एक कोड-गंध है।

— msw

@msw - कार्गो-पंथ कोडिंग।

— पीट बेकर

@msw - दूसरी ओर, यह आपको ब्रेकपॉइंट सेट करने के लिए जगह देता है।

— पीट बेकर

यह ऐसा है जैसे-यदि आप तर्क के पूरे हिस्से को छोड़ते हुए कोई मुद्दा नहीं देखते हैं। आपका संस्करण स्पष्ट रूप से मूल के समान काम नहीं करता है, जो वैसे, पहले से ही तेज और जोर से विफल हो जाता है। मैं आपके उत्तर के कैच-फ्री तरीकों को लिखना पसंद करता हूं, लेकिन मौजूदा कोड के साथ काम करते समय, हमें अन्य काम करने वाले हिस्सों के साथ अनुबंध नहीं तोड़ना चाहिए। यह हो सकता है कि जो कुछ किया गया है rethrowवह बेकार है (और यह यहाँ बात नहीं है), लेकिन आप बस उस कोड से छुटकारा नहीं पा सकते जो आपको पसंद नहीं है और यह कहना है कि यह मूल के बराबर है जब यह स्पष्ट रूप से नहीं है। कस्टम rethrowफ़ंक्शन में साइड-इफेक्ट होते हैं ।

— coredump

@ jpmc26 प्रश्न का मूल "यहाँ तक नहीं पहुँच सकता" अपवाद के बारे में है, जो पूर्ववर्ती कोशिश / कैच ब्लॉक से अलग अन्य कारणों से उत्पन्न हो सकता है। लेकिन मैं मानता हूं कि ब्लॉक में बदबू आती है, और यदि यह उत्तर मूल रूप से अधिक सावधानीपूर्वक लिखा जाता है, तो इससे बहुत अधिक वृद्धि हुई होगी (मैंने डाउनवोट, बीडब्ल्यूटी नहीं किया था)। अंतिम संपादन अच्छा है।

— coredump