2011-08-19 31 views
5

इस कोड पर विचार करेंकोड विश्लेषण शिकायत करता है कि मैं वस्तुओं का निपटारा नहीं कर रहा हूं। यहाँ क्या गलत है?

private MailMessage GetMailMessageFromMailItem(Data.SystemX.MailItem mailItem) 
     { 

      var msg = new MailMessage(); 

      foreach (var recipient in mailItem.MailRecipients) 
      { 
       var recipientX = Membership.GetUser(recipient.UserKey); 
       if (recipientX == null) 
       { 
        continue; 
       } 

       msg.To.Add(new MailAddress(recipientX.Email, recipientX.UserName)); 
      } 

      msg.From = new MailAddress(ConfigurationManager.AppSettings["EmailSender"], 
            ConfigurationManager.AppSettings["EmailSenderName"]); 

      msg.Subject = sender.UserName; 
      if (!string.IsNullOrEmpty(alias)) msg.Subject += "(" + alias + ")"; 
      msg.Subject += " " + mailItem.Subject; 
      msg.Body = mailItem.Body; 
      msg.Body += Environment.NewLine + Environment.NewLine + "To reply via Web click link below:" + Environment.NewLine; 
      msg.Body += ConfigurationManager.AppSettings["MailPagePath"] + "?AID=" + ContextManager.AccountId + "&RUN=" + sender.UserName; 

      if (mailItem.MailAttachments != null) 
      { 
       foreach (var attachment in mailItem.MailAttachments) 
       { 
        msg.Attachments.Add(new Attachment(new MemoryStream(attachment.Data), attachment.Name)); 
       } 
      } 

      return msg; 
     } 

मैं बस अपना डेटाबेस प्रकार ले रहा हूँ और MailMessage को बदलने। यह किसी अन्य फ़ंक्शन में भेजा जाता है।

कोड विश्लेषण मुझे बताता है कि मैं "संदेश" का निपटारा नहीं कर रहा हूं जो सही है। लेकिन अगर मैं इसे यहां करता हूं - जब मैं इसे भेजने की कोशिश कर रहा हूं तो मुझे अपवाद मिलता है।

इसके अलावा, इसके बारे में यहाँ MemoryStream निपटान नहीं शिकायत:

msg.Attachments.Add (नई अनुलग्नक (नई MemoryStream (attachment.Data), attachment.Name));

मुझे इस बात का कोई अंदाजा नहीं है कि इसे ठीक तरीके से निपटाने के तरीके के बारे में कोई जानकारी नहीं है। मैंने अलग-अलग चीजों की कोशिश की, लेकिन "स्ट्रीम बंद हो गया है" कहने पर मेल भेजते समय अपवाद प्राप्त हो रहा था, "

उत्तर

2

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

मेरा सुझाव है कि आप इस विधि के लिए चेतावनी दबाएं।

संपादित करें: मुझे संदेह है कि आप संदेश को दबाने के लिए [SuppressMessage] का उपयोग कर सकते हैं।


नोट एक जोखिम है कि कुछ कोड ताकि आप अंत कभी नहीं संदेश के निपटान के लिए भले ही आप बुला कोड में एक using बयान है सक्षम किया जा रहा विधि के माध्यम से कोड आधे रास्ते फेंक देते हैं, उपलब्ध न हो। यदि आप वास्तव में परेशान हैं, तो आप लिख सकते हैं:

private MailMessage GetMailMessageFromMailItem(Data.SystemX.MailItem mailItem) 
{ 
    bool success = false; 
    var msg = new MailMessage(); 
    try 
    { 
     // Code to build up bits of the message 
     success = true; 
     return msg; 
    } 
    finally 
    { 
     if (!success) 
     { 
      msg.Dispose(); 
     } 
    } 
} 

व्यक्तिगत रूप से मैं कहूंगा कि यह अधिक है हालांकि।

+0

मैं चेतावनियों को कैसे दबा सकता हूं? – katit

+0

@ कटिट: पास - मैं कोड विश्लेषण का उपयोग नहीं करता हूं। मुझे यकीन है कि ऑनलाइन बहुत सारे निर्देश हैं। –

+0

@Downvoter: टिप्पणी करने की देखभाल? –

0

"डिस्पोजेक्ट नहीं" संदेश के संबंध में, "एकमात्र तरीका जिसे मैं सोच सकता हूं, मेलमैसेज को वापस करने के बजाय मेलमेसेज के संदर्भ में पास करने के बजाय है। कुछ ऐसा है। यकीन नहीं है कि यह एक अच्छा विचार है।

private void GetMailMessageFromMailItem(ref MailMessage msg, Data.SystemX.MailItem mailItem) 
+0

मुझे संदेह है कि धारा संलग्नक में संग्रहीत की जाएगी और बाद में ही पढ़ी जाएगी। –

+0

@ जोन स्कीट, अब मैं इसके बारे में सोचता हूं, स्ट्रीम को खुले रहने की आवश्यकता होगी। – Jethro

-1

डिस्पोजेबल ऑब्जेक्ट के निर्माता को भी इसका निपटान करना चाहिए। यदि आप यहां संदेश का निपटान नहीं कर सकते हैं तो इसे कहीं और निर्माता से पास किया जाना चाहिए। कोड विश्लेषण इस मामले में सही है और यदि आप इन संदेशों को अनदेखा करते हैं तो आप लीक को डीबग करने के लिए बहुत दुर्भाग्यपूर्ण और कठिन हो सकते हैं।

+0

स्वामित्व हस्तांतरण एक बहुत ही उपयोगी अवधारणा है, दुर्भाग्य से न तो सी # और न ही कोड विश्लेषण सहायता प्रदान करता है। –

+0

इसलिए इसे टालना है। इस प्रकार यह अपने डिस्पोजेबल संसाधनों का निपटान करने के लिए निर्माता जिम्मेदारी असाइन करना बुद्धिमानी है। –

+0

निर्माता हमेशा तार्किक मालिक नहीं होता है। उदाहरण के लिए, कारखाने के पैटर्न में, निर्माता कभी मालिक नहीं होता है, न ही फैक्ट्री इसे संसाधनों का निपटान कर सकती है। इसके बजाए, एक अज्ञात संसाधन वापस किया जाना चाहिए। –