दिलचस्प पोस्ट
एक्सप्रेस-जेएस मेरी स्थैतिक फाइलें नहीं प्राप्त कर सकते हैं, क्यों? विज़ुअल स्टूडियो 2012 समाधान की टीमसिटी में एमएसब्लूल्ड ईविल जुड़वां समस्या और उपनगरीय विलय इकाई के ढांचे में एक इकाई वर्ग में एकाधिक तालिकाओं का मानचित्रण करना आपको कंस्ट्रक्टर के रूप में नंबर का उपयोग क्यों नहीं करना चाहिए? किसी UI के बिना गतिविधि कैसे लॉन्च की जाए? सी फ़ंक्शन के पूर्ण पूर्णांक मूल्य नियमित अभिव्यक्ति: संख्यात्मक श्रेणी टाइपिंग निश्चित लंबाई सरणी .NET के साथ एक सरणी को यादृच्छिक बनाने का सर्वोत्तम तरीका यादृच्छिक सूची से कोई आइटम कैसे चुनें? एसक्यूएल: बनाम <= और> = फेसबुक पोस्ट सभी प्रतिक्रियाओं को एक सिंगल ग्राफ एपीआई अनुरोध में गणना करना पायथन 'के साथ' वक्तव्य में कई चर मैं Laravel 5 में अपवादों / अनुपलब्ध पृष्ठों को कैसे प्राप्त करूं?

प्रतिक्रिया है। अंत () हानिकारक माना जाता है?

इस KB आलेख का कहना है कि एएसपी.नेट का Response.End() । एंड Response.End() एक थ्रेड को बंद कर देता है।

परावर्तक बताता है कि ऐसा लगता है:

 public void End() { if (this._context.IsInCancellablePeriod) { InternalSecurityPermissions.ControlThread.Assert(); Thread.CurrentThread.Abort(new HttpApplication.CancelModuleException(false)); } else if (!this._flushing) { this.Flush(); this._ended = true; if (this._context.ApplicationInstance != null) { this._context.ApplicationInstance.CompleteRequest(); } } } 

यह मुझे बहुत कठोर लगता है केबी के लेख के अनुसार, Response.End() में किसी भी कोड को क्रियान्वित नहीं किया जाएगा, और यह कम से कम विस्मय के सिद्धांत का उल्लंघन करेगा। यह WinForms ऐप में लगभग एप्लिकेशन की तरह है। Response.End() एंड Response.End() कारण थ्रेड अपवर्तित अपवाद पकड़ा जा सकता है, इसलिए कोड को आसपास के tryfinally संतुष्ट नहीं होगा।

इससे मुझे आश्चर्य होता है कि मुझे हमेशा Response.End() करना चाहिए। Response.End()

क्या कोई सुझाव दे सकता है, मुझे Response.End() एंड Response.Close() उपयोग कब करना चाहिए, जब Response.Close() और जब HttpContext.Current.ApplicationInstance.CompleteRequest() ?

रेफरी: रिक स्ट्रैहल का ब्लॉग एंट्री


मुझे मिले इनपुट के आधार पर, मेरा जवाब है, हाँ, Response.End हानिकारक है , लेकिन कुछ सीमित मामलों में यह उपयोगी है।

  • असाधारण स्थिति में तुरंत एचटीटीपीआरपीएसप को समाप्त करने के लिए Response.End() दें। डीबगिंग के दौरान भी उपयोगी हो सकता है। नियमित प्रतिक्रियाओं को पूरा करने के लिए Response.End() से बचें
  • क्लाइंट के साथ कनेक्शन को तत्काल बंद करने के लिए Response.Close() का उपयोग करें। इस एमएसडीएन ब्लॉग पोस्ट के अनुसार , यह विधि सामान्य HTTP अनुरोध प्रोसेसिंग के लिए अभिप्रेत नहीं है। यह अत्यधिक संभावना नहीं है कि आपके पास इस विधि को कॉल करने का एक अच्छा कारण होगा।
  • सामान्य अनुरोध समाप्त करने के लिए CompleteRequest() का उपयोग CompleteRequest() CompleteRequest HttpApplication इवेंट के पूरा होने के बाद, HttpApplication ASP.NET पाइपलाइन का कारण बनता है, HttpApplication इवेंट को आगे बढ़ सके। इसलिए यदि आप CompleteRequest कॉल करते हैं, तो प्रतिक्रिया के लिए कुछ और लिखें, लिखना ग्राहक को भेजा जाएगा।

संपादित करें – 13 अप्रैल 2011

आगे स्पष्टता यहां उपलब्ध है:
– एमएसडीएन ब्लॉग पर उपयोगी पोस्ट
– जॉन रीड द्वारा उपयोगी विश्लेषण

Solutions Collecting From Web of "प्रतिक्रिया है। अंत () हानिकारक माना जाता है?"

यदि आपने अपने ऐप पर एक अपवाद लकड़हारा लगाई थी, तो यह ThreadAbortException साथ इन सौहार्दपूर्ण Response.End() से पानी पिलाया जाएगा। ThreadAbortException Response.End() कॉल मुझे लगता है कि यह माइक्रोसॉफ्ट के कहने का तरीका है "इसे बंद करो!"

मैं केवल Response.End() उपयोग करता हूं। Response.End() अगर कोई असाधारण स्थिति थी और कोई अन्य कार्य संभव नहीं था। शायद तब, इस अपवाद को लॉगिंग वास्तव में एक चेतावनी का संकेत दे सकता है

टी एल; डॉ

शुरू में मैंने यह सिफारिश की थी कि आपको अपनी सभी कॉलों को [Response.End] को […] पूरा अनुरोध () कॉल के साथ बदलना चाहिए, लेकिन अगर आप पोस्टबैक प्रोसेसिंग और HTML रेंडरिंग से बचने के लिए चाहते हैं तो आपको जोड़ना होगा। ।] के रूप में अच्छी तरह से ओवरराइड।

जॉन रीड , "अंतिम विश्लेषण"


प्रति एमएसडीएन, जॉन रीड , और एलन रेनॉन:

एएसपी.NET प्रदर्शन – अपवाद प्रबंधन – अपवाद से बचने वाला कोड लिखें

सर्वर। ट्रांसफर, रिस्पांस। रीडायरेक्ट, रिस्पांस। एंड विधियाँ सभी अपवाद बढ़ाएं। इन विधियों में से प्रत्येक आंतरिक रूप से उत्तर दें। प्रतिक्रिया के लिए कॉल। अंत में, एक थ्रेडअबर्ट अपवाद अपवाद का कारण बनता है ।

थ्रेडअबर्टएक्सेप्शन सॉल्यूशन

HttpApplication.CompleteRequest () एक वेरिएबल सेट करता है जो धागा को एचटीटीपी अनुप्रयोग इवेंट पाइपलाइन में अधिकांश घटनाओं को छोड़ने का कारण बनता है [-] पेज इवेंट चेन नहीं बल्कि एप्लिकेशन इवेंट चेन।

एक क्लास स्तरीय वेरिएबल बनाएँ, जो झंडे यदि पेज को समाप्त कर देना चाहिए और फिर अपनी घटनाओं को संसाधित करने या अपने पेज को प्रस्तुति से पहले चर की जांच करनी चाहिए। […] मैं केवल RaisePostBackEvent और रेंडर विधियों को अधिलेखित करने की सिफारिश करेगा

रिस्पांस। एंड एंड रिस्पॉन्स। कॉन्ट्रैक्टेशन महत्वपूर्ण होने पर सामान्य अनुरोध प्रोसेसिंग में उपयोग नहीं किया जाता है। रिस्पांस। एंड एक सुविधाजनक, भारी-हाथ से संबंधित प्रदर्शन जुर्माना के साथ अनुरोध प्रोसेसिंग समाप्त करने का मतलब है। प्रतिक्रिया। बंद IIS / सॉकेट स्तर पर HTTP प्रतिक्रिया के तत्काल समापन के लिए है और KeepAlive जैसी चीजों के साथ मुद्दों का कारण बनता है।

ASP.NET अनुरोध समाप्त करने की अनुशंसित विधि है HttpApplication.CompleteRequest ध्यान रखें कि एएसपी.एन.टी.नेटिंग को मैन्युअल रूप से छोड़ना होगा क्योंकि एचटीटीपीएपीसीकरण। कॉम्पलेटेक्वेस्ट शेष IIS / ASP.NET अनुप्रयोग पाइपलाइन को छोड़ नहीं देता, न कि एएसपी.नेट पृष्ठ पाइपलाइन (जो एप पाइपलाइन में एक चरण है)।


कोड

कॉपीराइट © 2001-2007, सी 6 सॉफ्टवेयर, इंक के रूप में सबसे अच्छा मैं बता सकता है


संदर्भ

HttpApplication.CompleteRequest

सभी घटनाओं को बाधित करने और निष्पादन की HTTP पाइपलाइन श्रृंखला में फ़िल्टरिंग और सीधे EndRequest ईवेंट निष्पादित करने के लिए ASP.NET का कारण बनता है।

Response.End

यह पद्धति केवल एएसपी के साथ संगतता के लिए प्रदान की जाती है, जो कि एसएपी.नेट से पूर्ववर्ती ASP.NET से पहले कॉम-आधारित वेब-प्रोग्रामिंग तकनीक के साथ संगतता के लिए है। [महत्व दिया]

Response.Close

इस विधि ने ग्राहक को कनेक्शन को अचानक तरीके से समाप्त कर दिया है और सामान्य HTTP अनुरोध प्रसंस्करण के लिए अभिप्रेत नहीं है । [महत्व दिया]

यह प्रश्न प्रतिक्रिया के बारे में जानकारी के लिए सभी Google खोजों के शीर्ष के निकट दिखाई देता है। इसलिए मेरे जैसे अन्य खोजों के लिए, जो पूरे एएसपीएक्स पृष्ठ को बिना किसी घटना के जवाब में सीएसवी / एक्सएमएल / पीडीएफ़ आदि पोस्ट करना चाहते हैं, इस तरह मैं इसे करता हूं । (रेंडर विधियों को ओवरराइड करना एक ऐसी सरल कार्य आईएमओ के लिए अति जटिल है)

 // Add headers for a csv file or whatever Response.ContentType = "text/csv" Response.AddHeader("Content-Disposition", "attachment;filename=report.csv") Response.AddHeader("Pragma", "no-cache") Response.AddHeader("Cache-Control", "no-cache") // Write the data as binary from a unicode string Dim buffer As Byte() buffer = System.Text.Encoding.Unicode.GetBytes(csv) Response.BinaryWrite(buffer) // Sends the response buffer Response.Flush() // Prevents any other content from being sent to the browser Response.SuppressContent = True // Directs the thread to finish, bypassing additional processing HttpContext.Current.ApplicationInstance.CompleteRequest() 

"मैं अभी भी प्रतिक्रिया के बीच का अंतर नहीं जानता। Close और CompleteRequest ()" मैं कहूंगा:

पूर्णरूट () को पसंद करें, प्रतिक्रिया का उपयोग न करें। बंद करें ()

इस मामले की अच्छी तरह से तैयार सारणी के लिए निम्नलिखित लेख देखें।

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

बीटीडब्लू: मैं रिस्पांस। एंड () का उपयोग करने से बचने के लिए सहमत हूं, विशेषकर जब फ़ाइल स्ट्रीम को डाटा डाउनलोड करने के लिए एचटीटीपी स्ट्रीम में डेटा लिखना हमने रिस्पांस। एंड () को पिछले समय तक प्रयोग किया है जब तक कि हमारी लॉग फ़ाइल थ्रेडएबर्ट एक्सपेशन्स से भरा न हो

मैं बयान के साथ असहमत हूं " प्रतिक्रियाअंत हानिकारक है " यह निश्चित रूप से हानिकारक नहीं है प्रतिक्रिया। यह क्या करता है; यह पृष्ठ का निष्पादन समाप्त होता है परावर्तक का उपयोग करने के लिए यह देखने के लिए कि इसे कैसे लागू किया गया था, उसे केवल शिक्षाप्रद के रूप में देखा जाना चाहिए।


मेरी 2cent सिफारिश
Response.End() एंड Response.End() नियंत्रण प्रवाह के रूप में प्रयोग से बचें
यदि आपको अनुरोध निष्पादन को रोकने की आवश्यकता है और सावधान रहें कि (आमतौर पर) उत्तर * प्रत्युत्तर दें।


* Response.End() और थ्रेडएबर्टएक्सप्शन एस।

Response.End() थ्रेड एबॉर्ट एक्सपेशेशन को वर्तमान कार्यान्वयन के हिस्से के रूप में फेंकता है (जैसा कि ओपी ने बताया है)।

ThreadAbortException एक विशेष अपवाद है जिसे पकड़ा जा सकता है, लेकिन कैच ब्लॉक के अंत में इसे स्वचालित रूप से फिर से उठाया जाएगा।

थ्रेडएबर्ट एक्सक्शपेशन से निपटने के लिए कोड लिखने के तरीके के बारे में देखने के लिए, देखें @ मेहरदद का जवाब SO आखिरकार ब्लॉक में एक थैरेबर्ट एक्सपैशन का पता लगा सकता है जहां वह रनटाइमहल्पर को संदर्भित करता है। एक्सक्टेक कोडवथ गारंटीकृत क्लीनअप विधि और बाध्य कार्य निष्पादन क्षेत्र


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

मैंने कार्यक्रम के प्रवाह को नियंत्रित करने के लिए Response.End () का उपयोग नहीं किया है।

हालांकि Response.End () उदाहरण के लिए उपयोगी हो सकता है जब किसी उपयोगकर्ता को फाइलों की सेवा करते हैं।

आपने फ़ाइल को प्रतिक्रिया के लिए लिखा है और आप प्रतिक्रिया के लिए और कुछ जोड़ना नहीं चाहते हैं, क्योंकि यह आपकी फ़ाइल को भ्रष्ट कर सकती है।

मैंने दोनों के लिए एनोट और क्लासिक एएसपी में उत्तरदायित्व का इस्तेमाल किया है। उदाहरण के लिए, मैं इसका उपयोग तब करता हूं जब लॉगिन प्रयासों का प्रमाणन राशि होती है या जब एक सुरक्षित पृष्ठ एक अप्रमाणित लॉगिन (गलत उदाहरण) से जोड़ा जा रहा है:

  if (userName == "") { Response.Redirect("......"); Response.End(); } else { ..... 

जब किसी उपयोगकर्ता को फाइलों की सेवा करने पर मैं फ्लश का उपयोग करता हूं, तो अंत समस्या पैदा कर सकता है।

मैंने केवल एक प्रतिक्रिया / डीबगिंग तंत्र के रूप में Response.End () का उपयोग किया है

 <snip> Response.Write("myVariable: " + myVariable.ToString()); Response.End(); <snip> 

अनुसंधान के संदर्भ में आपने जो पोस्ट किया है उसे देखते हुए, मैं कहूंगा कि यदि यह आवश्यक है तो यह एक बुरा डिजाइन होगा