2015-07-15 12 views
7

मुझे Exception कक्षाएं बनाना पसंद हैं जिनके नाम एप्लिकेशन-विशिष्ट समस्याओं को ध्यान में रखते हुए फेंकते हैं।कस्टम जावा अपवाद कक्षाओं के भीतर दोहराव से कैसे बचें

उन्हें परिभाषित करने के लिए, आम तौर पर एक नया class परिभाषित किया जाता है जिसका सुपर-क्लास कुछ Exception प्रकार है।

माता पिता Exception वर्ग में एक से अधिक आम कंस्ट्रक्टर्स के कारण, आम तौर पर उप-वर्ग इस तरह दिखता है:

package com.example.exception; 

/** 
* MyException is thrown when some application-level expectation is not met. 
*/ 
public class MyException extends Exception { 

    public MyException() { 
     super(); 
    } 

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

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

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

} 

DRY के नजरिए से इस को देखते हुए, मैं इस दृष्टिकोण थकाऊ मिल जाए, विशेष रूप से जब Exception पदानुक्रम परिभाषित किए गए हैं।

मैं Lombok जैसे उपकरणों से परिचित हूं जो सामान्य जावा पैटर्न के लिए पुनरावृत्ति को कम करने में मदद करता है; क्या ऐसे औजारों के लिए कोई सुझाव हैं जो अपवाद वर्गों के लिए पुनरावृत्ति की इस विशिष्ट समस्या से निपटते हैं?

+2

यह मेरे लिए ठीक लग रहा है। –

+0

@SotiriosDelimanolis मेरा मानना ​​है कि ओपी जिस बिंदु को बनाने की कोशिश कर रहा है वह यह है कि यदि उसके पास 10 कस्टम अपवाद वर्ग हैं, तो उन्हें इन सभी अपवाद वर्गों में इस कोड को दोहराना होगा। – CKing

+2

@CKing नहीं, मुझे यह मिल गया। यह मेरे साथ ठीक होगा। –

उत्तर

4

यदि आप "व्यवसाय" अपवाद बनाते हैं, तो आपको Exception से सभी रचनाकारों की प्रतिलिपि नहीं लेनी चाहिए। इसके बजाय, अपवाद बनाएं जो आपके व्यावसायिक ऑब्जेक्ट्स का उपयोग करें। उदाहरण के लिए, विफल होने पर एक अनुरोध है जो आपके व्यवसाय वस्तु Request द्वारा मॉडलिंग की है आप एक ही निर्माता के साथ एक RequestFailedException बना सकता है:

public RequestFailedException(Request request) { 
    super("Request to " + request.getUrl() + " failed."; 
} 

तुम भी एक क्षेत्र में Request ऑब्जेक्ट के संदर्भ संग्रहीत कर सकती है और इसलिए एक गेटर प्रदान कि अपवाद को संभालने वाली विधि को क्या हो रहा था इसके बारे में अधिक जानकारी मिल सकती है।

+1

मैं मानता हूं कि कुछ 'अपवाद' के लिए, प्रासंगिक जानकारी को समाहित करना एक अच्छा विचार है, लेकिन सभी 'अपवाद की आवश्यकता नहीं है; सबसे अधिक 'अपवाद' सिर्फ कस्टम नामित रैपर नहीं हैं? मुझे बस यह परेशान लगता है कि 'अपवाद' के उन सभी प्रकार के लिए, यह सब डुप्लिकेट कोड बनाया गया है। –

+1

मुझे लगता है कि हम (जावा डेवलपर्स) अक्सर अपवाद फेंकते हैं। उदाहरण के लिए, किसी विधि को लागू करने के बजाय पहले से कुछ शर्त जांचने के तरीकों की पेशकश करने का प्रयास करें, जो शर्त पूरी नहीं होने पर अपवाद फेंकता है। इसके अलावा, अगर कुछ गलत हो जाता है, तो लचीला होने की कोशिश करें और कुछ ऐसा न करें जो सही नहीं हो सकता है लेकिन कॉलर के लिए अभी भी उपयोगी है। – hzpz

+1

जबकि मैं पूरी तरह से सहमत हूं कि यह उत्तर क्या कहता है, ओपी ने यह नहीं पूछा है। –

संबंधित मुद्दे