2011-03-21 13 views
6

मैं स्प्रिंग 3 और हाइबरनेट 3.6 के साथ एक वेबप्लिकेशंस विकसित करने पर काम कर रहा हूं। मुझे @Transactional एनोटेशन और कोड की संरचना के लिए कुछ प्रश्न हैं।हाइबरनेट, वसंत, @ ट्रांस्सेक्शन - कोशिश/पकड़ के साथ घिरा हुआ?

-> जब मैं @Transactional (वसंत के साथ लेनदेन प्रबंधन) का उपयोग करता हूं, तो क्या मुझे @Transactional -Nototated विधियों को कॉल करते समय कोशिश/पकड़ने के साथ घूमना पड़ता है?

उदाहरण के लिए, जब मैं एक तरीका है जिसके लोड करता है, परिवर्तन और रिटर्न तो एक वस्तु हो गया और मैं किसी अन्य वर्ग से इसे कहते हैं: मैं कोशिश के साथ कॉल के चारों ओर की क्या ज़रूरत है/पकड़ने? शायद कुछ गलत हो जाता है, कोई वस्तु वापस नहीं आती है, डेटाबेस कनेक्शन विफल रहता है .. मुझे नहीं पता।

अब तक, मैंने सोचा था कि @Transactional सभी संभावित होने वाले अपवादों की परवाह करता है और जब कोई त्रुटि होती है तो इस लेनदेन में प्रत्येक ऑपरेशन को वापस रोल करता है। लेकिन यदि ऐसा होता है, तो मुझे किसी भी तरह उपयोगकर्ता को सूचित करना होगा। जब मैं कोशिश-ब्लॉक में लेन-देन-विधि को कॉल करता हूं और इसे वापस ले जाता है, तो कैच ब्लॉक सक्रिय होता है? मैं तब उपयोगकर्ता को बता सकता हूं कि "कुछ गलत हो गया"। अन्यथा उपयोगकर्ता को सूचित नहीं किया जाएगा?

या यह अगर वहाँ एक वस्तु लौट आए (/ else if), तो मैं कोशिश की जरूरत है न/पकड़ने की जाँच करने के लिए पर्याप्त है? मैं नया हूं और मैं सुनना चाहता हूं कि उनके कोड की अन्य संरचना कैसे होती है। धन्यवाद :-)

उत्तर

4

वसंत में Handling exceptions HandlerExceptionResolvers और @ExceptionHandlers साथ बहुत आसान है। मैं विशेष रूप से @ExceptionHandler का उपयोग करता हूं।

तुम खुद एक कोशिश पकड़ ब्लॉक में से निपटने के बजाय एक विशिष्ट अपवाद को संभालने के लिए एक @ExceptionHandler उपयोग कर सकते हैं।

उपयोगकर्ता एक संसाधन है कि नहीं मिला था चाहता था और आप एक 404.

@ExceptionHandler(NotFoundException.class) 
@ResponseStatus(HttpStatus.NOT_FOUND) 
public void handleNotFoundException(NotFoundException exc) { 
    // log something. 
} 

भेजना चाहते हैं वहाँ एक सर्वर मुद्दा है जहाँ आप एक 500

@ExceptionHandler(SomeException.class) 
public void handleException(SomeException exc, WebRequest request, HttpServletResponse response) { 
    response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "Sorry dude, my server broke"); 
} 
भेजना चाहते होता था तो

आपको अपवादों को संकीर्ण रूप से संभालना चाहिए। आम तौर पर आपको @ExceptionHandler(Exception.class) नहीं करना चाहिए और मुझे यह भी विश्वास है कि यह क्रम में काम करता है, इसलिए यदि आप सामान्य अपवाद को संभालते हैं तो यह कक्षा में अंतिम विधि होनी चाहिए।

+0

क्या आप कोड उदाहरण के बारे में गंभीर हैं? अपवादों को इस तरह निगलना नहीं चाहिए। इस तरह प्रॉक्सी अपवाद का पता लगाने और लेनदेन को वापस रोल करने का कोई मौका नहीं है। मुझे उम्मीद है कि आप इस तरह कुछ मतलब करेंगे: 'पकड़ो (कुछ एक्सेप्शन एक्स) {नया अवैध स्टेटस्ट एक्सेप्शन (एक्स्ट) फेंक दें;} ' –

+0

@ सेन यह सिर्फ छद्म कोड है। मुझे उम्मीद है कि वह जब तक एक अपवाद निगल नहीं है ऐसा करने का उसका एक अच्छा कारण था। –

+0

यही कारण है कि मैं पूछ रहा हूं, डाउनवॉटिंग नहीं। आपको इस तरह की चीजों को स्पष्ट करना चाहिए, –

1

वसंत द्वारा उपयोग की जाने वाली मुख्य विशेषता Exception Translation है।

अपवाद अनुवाद पर भरोसा करते हैं अपवाद अपने ग्राहक परत को समझता पैदा करते हैं और कोशिश का उपयोग/केवल वहाँ पकड़ने, यदि संभव हो करने के लिए।

0

मुझे जवाब देने के लिए धन्यवाद। मैंने लिंक (वसंत दस्तावेज) के माध्यम से पढ़ा और मुझे निम्नलिखित पाया:

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

मेरे डीएओ, पर सादा हाइबरनेट 3 एपीआई आधारित इसलिए अगर मैं इसे सही समझते हैं, मेरी डीएओ केवल सादे HibernateExceptions फेंकता है।वे अनचेक हैं और घोषित या पकड़े जाने की आवश्यकता नहीं है। अगर कुछ गलत हो जाता है, तो @ ट्रान्सएक्शनल के साथ पूरा ऑपरेशन वापस लुढ़का जाता है।

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

तो इस बिंदु पर, मैं अभी भी सोच रहा हूं कि - लेनदेन के आधार पर: यदि मैं परिणाम के साथ काम कर सकता हूं, तो सब कुछ ठीक है - यदि नहीं, तो मैं उपयोगकर्ता को सूचित कर सकता हूं।

जब लेनदेन को परिणाम देने के लिए निर्दिष्ट नहीं किया गया है, तो मैं एक हाइबरनेट अपवाद को पकड़ने के लिए प्रयास/पकड़ का उपयोग कर सकता हूं। लेकिन क्या लेनदेन अभी भी वापस लुढ़का है? मैंने सोचा, एक हाइबरनेट अपवाद को पकड़ना लेनदेन के रोलिंग बैक से बचाता है। मुझे अभी भी पता नहीं है कि क्या करना है। :-(

इस के अलावा के

दुर्भाग्य से मैं समझता हूँ कि नहीं क्या MVC अपवाद हैंडलिंग (@ExceptionHandler) इस से कोई लेना देना नहीं है। संभाला अपवाद की एक मेज था, लेकिन मैं HibernateException नहीं मिला। या आपको लगता है कर यह इसके साथ काम करेगा: @ExceptionHandler (HibernateException.classs)? आपने यह भी कहा कि आप इस तरह अपवादों को संभालने की अनुशंसा नहीं करेंगे।

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