कस्टम .NET एक्सेप्शन सीरियल करने योग्य बनाने का सही तरीका क्या है?

Question

अधिक विशेष रूप से, जब अपवाद में कस्टम ऑब्जेक्ट्स होते हैं जो स्वयं अनुक्रमित हो सकते हैं या नहीं हो सकते हैं।

इस उदाहरण को लें:

public class MyException : Exception
{
    private readonly string resourceName;
    private readonly IList<string> validationErrors;

    public MyException(string resourceName, IList<string> validationErrors)
    {
        this.resourceName = resourceName;
        this.validationErrors = validationErrors;
    }

    public string ResourceName
    {
        get { return this.resourceName; }
    }

    public IList<string> ValidationErrors
    {
        get { return this.validationErrors; }
    }
}

यदि यह अपवाद अनुक्रमित और डी-क्रमांकित है, तो दो कस्टम गुण ( ResourceNameऔर ValidationErrors) संरक्षित नहीं होंगे। गुण लौटेंगे null।

क्या कस्टम अपवाद के लिए क्रमांकन लागू करने के लिए एक सामान्य कोड पैटर्न है?

Answer 1

कस्टम गुणों के बिना बेस कार्यान्वयन

SerializableExceptionWithoutCustomProperties.cs:

namespace SerializableExceptions
{
    using System;
    using System.Runtime.Serialization;

    [Serializable]
    // Important: This attribute is NOT inherited from Exception, and MUST be specified 
    // otherwise serialization will fail with a SerializationException stating that
    // "Type X in Assembly Y is not marked as serializable."
    public class SerializableExceptionWithoutCustomProperties : Exception
    {
        public SerializableExceptionWithoutCustomProperties()
        {
        }

        public SerializableExceptionWithoutCustomProperties(string message) 
            : base(message)
        {
        }

        public SerializableExceptionWithoutCustomProperties(string message, Exception innerException) 
            : base(message, innerException)
        {
        }

        // Without this constructor, deserialization will fail
        protected SerializableExceptionWithoutCustomProperties(SerializationInfo info, StreamingContext context) 
            : base(info, context)
        {
        }
    }
}

पूर्ण कार्यान्वयन, कस्टम गुणों के साथ

एक कस्टम क्रमिक अपवाद ( MySerializableException), और एक व्युत्पन्न sealedअपवाद ( MyDerivedSerializableException) का पूर्ण कार्यान्वयन ।

इस कार्यान्वयन के बारे में मुख्य बातें यहाँ संक्षेप में प्रस्तुत की गई हैं:

1. आपको प्रत्येक व्युत्पन्न वर्ग को [Serializable]विशेषता के साथ सजाना होगा - यह विशेषता आधार वर्ग से विरासत में नहीं मिली है, और यदि यह निर्दिष्ट नहीं है, तो क्रमांकन यह SerializationExceptionबताते हुए विफल हो जाएगा कि "असेंबली में टाइप X को क्रमबद्धता के रूप में चिह्नित नहीं किया गया है।"
2. आपको कस्टम क्रमांकन लागू करना होगा । केवल [Serializable]विशेषता ही पर्याप्त नहीं है - Exceptionलागू होने ISerializableका मतलब है कि आपके व्युत्पन्न वर्गों को भी कस्टम क्रमांकन को लागू करना चाहिए। इसमें दो चरण शामिल हैं:
   1. एक क्रमिक निर्माण प्रदान करें । यह निर्माणकर्ता तब होना चाहिए privateजब आपकी कक्षा हो sealed, अन्यथा यह protectedव्युत्पन्न वर्गों तक पहुंच की अनुमति होनी चाहिए ।
   2. GetObjectData () को ओवरराइड करें और सुनिश्चित करें कि आप base.GetObjectData(info, context)अंत में कॉल करते हैं, ताकि आधार वर्ग को अपना राज्य बचा सके।

SerializableExceptionWithCustomProperties.cs:

namespace SerializableExceptions
{
    using System;
    using System.Collections.Generic;
    using System.Runtime.Serialization;
    using System.Security.Permissions;

    [Serializable]
    // Important: This attribute is NOT inherited from Exception, and MUST be specified 
    // otherwise serialization will fail with a SerializationException stating that
    // "Type X in Assembly Y is not marked as serializable."
    public class SerializableExceptionWithCustomProperties : Exception
    {
        private readonly string resourceName;
        private readonly IList<string> validationErrors;

        public SerializableExceptionWithCustomProperties()
        {
        }

        public SerializableExceptionWithCustomProperties(string message) 
            : base(message)
        {
        }

        public SerializableExceptionWithCustomProperties(string message, Exception innerException)
            : base(message, innerException)
        {
        }

        public SerializableExceptionWithCustomProperties(string message, string resourceName, IList<string> validationErrors)
            : base(message)
        {
            this.resourceName = resourceName;
            this.validationErrors = validationErrors;
        }

        public SerializableExceptionWithCustomProperties(string message, string resourceName, IList<string> validationErrors, Exception innerException)
            : base(message, innerException)
        {
            this.resourceName = resourceName;
            this.validationErrors = validationErrors;
        }

        [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = true)]
        // Constructor should be protected for unsealed classes, private for sealed classes.
        // (The Serializer invokes this constructor through reflection, so it can be private)
        protected SerializableExceptionWithCustomProperties(SerializationInfo info, StreamingContext context)
            : base(info, context)
        {
            this.resourceName = info.GetString("ResourceName");
            this.validationErrors = (IList<string>)info.GetValue("ValidationErrors", typeof(IList<string>));
        }

        public string ResourceName
        {
            get { return this.resourceName; }
        }

        public IList<string> ValidationErrors
        {
            get { return this.validationErrors; }
        }

        [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = true)]
        public override void GetObjectData(SerializationInfo info, StreamingContext context)
        {
            if (info == null)
            {
                throw new ArgumentNullException("info");
            }

            info.AddValue("ResourceName", this.ResourceName);

            // Note: if "List<T>" isn't serializable you may need to work out another
            //       method of adding your list, this is just for show...
            info.AddValue("ValidationErrors", this.ValidationErrors, typeof(IList<string>));

            // MUST call through to the base class to let it save its own state
            base.GetObjectData(info, context);
        }
    }
}

DerivedSerializableExceptionWithAdditionalCustomProperties.cs:

namespace SerializableExceptions
{
    using System;
    using System.Collections.Generic;
    using System.Runtime.Serialization;
    using System.Security.Permissions;

    [Serializable]
    public sealed class DerivedSerializableExceptionWithAdditionalCustomProperty : SerializableExceptionWithCustomProperties
    {
        private readonly string username;

        public DerivedSerializableExceptionWithAdditionalCustomProperty()
        {
        }

        public DerivedSerializableExceptionWithAdditionalCustomProperty(string message)
            : base(message)
        {
        }

        public DerivedSerializableExceptionWithAdditionalCustomProperty(string message, Exception innerException) 
            : base(message, innerException)
        {
        }

        public DerivedSerializableExceptionWithAdditionalCustomProperty(string message, string username, string resourceName, IList<string> validationErrors) 
            : base(message, resourceName, validationErrors)
        {
            this.username = username;
        }

        public DerivedSerializableExceptionWithAdditionalCustomProperty(string message, string username, string resourceName, IList<string> validationErrors, Exception innerException) 
            : base(message, resourceName, validationErrors, innerException)
        {
            this.username = username;
        }

        [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = true)]
        // Serialization constructor is private, as this class is sealed
        private DerivedSerializableExceptionWithAdditionalCustomProperty(SerializationInfo info, StreamingContext context)
            : base(info, context)
        {
            this.username = info.GetString("Username");
        }

        public string Username
        {
            get { return this.username; }
        }

        public override void GetObjectData(SerializationInfo info, StreamingContext context)
        {
            if (info == null)
            {
                throw new ArgumentNullException("info");
            }
            info.AddValue("Username", this.username);
            base.GetObjectData(info, context);
        }
    }
}

---

यूनिट टेस्ट

उपरोक्त परिभाषित तीन अपवाद प्रकारों के लिए MSTest इकाई परीक्षण।

UnitTests.cs:

namespace SerializableExceptions
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.Runtime.Serialization.Formatters.Binary;
    using Microsoft.VisualStudio.TestTools.UnitTesting;

    [TestClass]
    public class UnitTests
    {
        private const string Message = "The widget has unavoidably blooped out.";
        private const string ResourceName = "Resource-A";
        private const string ValidationError1 = "You forgot to set the whizz bang flag.";
        private const string ValidationError2 = "Wally cannot operate in zero gravity.";
        private readonly List<string> validationErrors = new List<string>();
        private const string Username = "Barry";

        public UnitTests()
        {
            validationErrors.Add(ValidationError1);
            validationErrors.Add(ValidationError2);
        }

        [TestMethod]
        public void TestSerializableExceptionWithoutCustomProperties()
        {
            Exception ex =
                new SerializableExceptionWithoutCustomProperties(
                    "Message", new Exception("Inner exception."));

            // Save the full ToString() value, including the exception message and stack trace.
            string exceptionToString = ex.ToString();

            // Round-trip the exception: Serialize and de-serialize with a BinaryFormatter
            BinaryFormatter bf = new BinaryFormatter();
            using (MemoryStream ms = new MemoryStream())
            {
                // "Save" object state
                bf.Serialize(ms, ex);

                // Re-use the same stream for de-serialization
                ms.Seek(0, 0);

                // Replace the original exception with de-serialized one
                ex = (SerializableExceptionWithoutCustomProperties)bf.Deserialize(ms);
            }

            // Double-check that the exception message and stack trace (owned by the base Exception) are preserved
            Assert.AreEqual(exceptionToString, ex.ToString(), "ex.ToString()");
        }

        [TestMethod]
        public void TestSerializableExceptionWithCustomProperties()
        {
            SerializableExceptionWithCustomProperties ex = 
                new SerializableExceptionWithCustomProperties(Message, ResourceName, validationErrors);

            // Sanity check: Make sure custom properties are set before serialization
            Assert.AreEqual(Message, ex.Message, "Message");
            Assert.AreEqual(ResourceName, ex.ResourceName, "ex.ResourceName");
            Assert.AreEqual(2, ex.ValidationErrors.Count, "ex.ValidationErrors.Count");
            Assert.AreEqual(ValidationError1, ex.ValidationErrors[0], "ex.ValidationErrors[0]");
            Assert.AreEqual(ValidationError2, ex.ValidationErrors[1], "ex.ValidationErrors[1]");

            // Save the full ToString() value, including the exception message and stack trace.
            string exceptionToString = ex.ToString();

            // Round-trip the exception: Serialize and de-serialize with a BinaryFormatter
            BinaryFormatter bf = new BinaryFormatter();
            using (MemoryStream ms = new MemoryStream())
            {
                // "Save" object state
                bf.Serialize(ms, ex);

                // Re-use the same stream for de-serialization
                ms.Seek(0, 0);

                // Replace the original exception with de-serialized one
                ex = (SerializableExceptionWithCustomProperties)bf.Deserialize(ms);
            }

            // Make sure custom properties are preserved after serialization
            Assert.AreEqual(Message, ex.Message, "Message");
            Assert.AreEqual(ResourceName, ex.ResourceName, "ex.ResourceName");
            Assert.AreEqual(2, ex.ValidationErrors.Count, "ex.ValidationErrors.Count");
            Assert.AreEqual(ValidationError1, ex.ValidationErrors[0], "ex.ValidationErrors[0]");
            Assert.AreEqual(ValidationError2, ex.ValidationErrors[1], "ex.ValidationErrors[1]");

            // Double-check that the exception message and stack trace (owned by the base Exception) are preserved
            Assert.AreEqual(exceptionToString, ex.ToString(), "ex.ToString()");
        }

        [TestMethod]
        public void TestDerivedSerializableExceptionWithAdditionalCustomProperty()
        {
            DerivedSerializableExceptionWithAdditionalCustomProperty ex = 
                new DerivedSerializableExceptionWithAdditionalCustomProperty(Message, Username, ResourceName, validationErrors);

            // Sanity check: Make sure custom properties are set before serialization
            Assert.AreEqual(Message, ex.Message, "Message");
            Assert.AreEqual(ResourceName, ex.ResourceName, "ex.ResourceName");
            Assert.AreEqual(2, ex.ValidationErrors.Count, "ex.ValidationErrors.Count");
            Assert.AreEqual(ValidationError1, ex.ValidationErrors[0], "ex.ValidationErrors[0]");
            Assert.AreEqual(ValidationError2, ex.ValidationErrors[1], "ex.ValidationErrors[1]");
            Assert.AreEqual(Username, ex.Username);

            // Save the full ToString() value, including the exception message and stack trace.
            string exceptionToString = ex.ToString();

            // Round-trip the exception: Serialize and de-serialize with a BinaryFormatter
            BinaryFormatter bf = new BinaryFormatter();
            using (MemoryStream ms = new MemoryStream())
            {
                // "Save" object state
                bf.Serialize(ms, ex);

                // Re-use the same stream for de-serialization
                ms.Seek(0, 0);

                // Replace the original exception with de-serialized one
                ex = (DerivedSerializableExceptionWithAdditionalCustomProperty)bf.Deserialize(ms);
            }

            // Make sure custom properties are preserved after serialization
            Assert.AreEqual(Message, ex.Message, "Message");
            Assert.AreEqual(ResourceName, ex.ResourceName, "ex.ResourceName");
            Assert.AreEqual(2, ex.ValidationErrors.Count, "ex.ValidationErrors.Count");
            Assert.AreEqual(ValidationError1, ex.ValidationErrors[0], "ex.ValidationErrors[0]");
            Assert.AreEqual(ValidationError2, ex.ValidationErrors[1], "ex.ValidationErrors[1]");
            Assert.AreEqual(Username, ex.Username);

            // Double-check that the exception message and stack trace (owned by the base Exception) are preserved
            Assert.AreEqual(exceptionToString, ex.ToString(), "ex.ToString()");
        }
    }
}

Comments

+1: लेकिन यदि आप इस समस्या के लिए जा रहे हैं, तो मैं सभी तरह से जाऊंगा और अपवादों को लागू करने के लिए सभी एमएस दिशानिर्देशों का पालन करूंगा। मुझे याद है कि मानक अवरोधक प्रदान करना है MyException (), MyException (स्ट्रिंग संदेश) और MyException (स्ट्रिंग संदेश, अपवाद भीतरी अपवाद)

— Joe

यह भी - कि फ्रेमवर्क डिज़ाइन गाइडेलिटी कहती है कि अपवादों के नाम "अपवाद" के साथ समाप्त होने चाहिए । MyExceptionAndHereIsaQualifyingAdverbialPhrase जैसा कुछ विस्थापित है। msdn.microsoft.com/en-us/library/ms229064.aspx किसी ने एक बार कहा था, जो कोड हम यहां प्रदान करते हैं वह अक्सर एक पैटर्न के रूप में उपयोग किया जाता है, इसलिए हमें इसे सही पाने के लिए सावधान रहना चाहिए।

— चेसो

चीज़ो: डिजाइनिंग कस्टम अपवादों पर अनुभाग में पुस्तक "फ्रेमवर्क डिज़ाइन दिशानिर्देश", कहती है: "सभी अपवादों पर इन सामान्य रचनाकारों को प्रदान करें (कम से कम)।" यहाँ देखें: blogs.msdn.com/kcwalina/archive/2006/07/05/657268.aspx केवल धारावाहिककरण के संदर्भ में (SerializationInfo जानकारी, StreamingContext संदर्भ) निर्माणकर्ता को क्रमिक शुद्धता के लिए आवश्यक है, बाकी को यह एक अच्छा प्रारंभिक बिंदु बनाने के लिए प्रदान किया गया है काटो और चिपकाओ। जब आप काटते हैं और पेस्ट करते हैं, तो आप निश्चित रूप से वर्ग के नामों को बदल देंगे, इसलिए मुझे नहीं लगता कि अपवाद नामकरण सम्मेलन का उल्लंघन यहां महत्वपूर्ण है ...

— डैनियल फोर्टुनोव

क्या यह स्वीकृत उत्तर .NET .NET के लिए भी सही है? .Net कोर में GetObjectDataकभी भी ToString()आह्वान नहीं किया जाता है..जब भी मैं ओवरराइड कर सकता हूं जो आमंत्रित किया जाता है

— LP13

ऐसा लगता है कि यह वे नहीं है जिस तरह से यह नई दुनिया में किया जाता है। उदाहरण के लिए, ASP.NET Core में शाब्दिक रूप से कोई अपवाद इस तरह से लागू नहीं किया गया है। वे सभी क्रमबद्ध सामान छोड़ देते हैं: github.com/aspnet/Mvc/blob/…

— bitbonk

Answer 2

अपवाद पहले से ही सीरियल करने योग्य है, लेकिन आपको GetObjectDataअपने चर को संग्रहीत करने के लिए विधि को ओवरराइड करने और एक निर्माता प्रदान करने की आवश्यकता है जिसे आपकी वस्तु को फिर से हाइड्रेट करते समय कहा जा सकता है।

तो आपका उदाहरण बनता है:

[Serializable]
public class MyException : Exception
{
    private readonly string resourceName;
    private readonly IList<string> validationErrors;

    public MyException(string resourceName, IList<string> validationErrors)
    {
        this.resourceName = resourceName;
        this.validationErrors = validationErrors;
    }

    public string ResourceName
    {
        get { return this.resourceName; }
    }

    public IList<string> ValidationErrors
    {
        get { return this.validationErrors; }
    }

    [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter=true)]
    protected MyException(SerializationInfo info, StreamingContext context) : base (info, context)
    {
        this.resourceName = info.GetString("MyException.ResourceName");
        this.validationErrors = info.GetValue("MyException.ValidationErrors", typeof(IList<string>));
    }

    [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter=true)]
    public override void GetObjectData(SerializationInfo info, StreamingContext context)
    {
        base.GetObjectData(info, context);

        info.AddValue("MyException.ResourceName", this.ResourceName);

        // Note: if "List<T>" isn't serializable you may need to work out another
        //       method of adding your list, this is just for show...
        info.AddValue("MyException.ValidationErrors", this.ValidationErrors, typeof(IList<string>));
    }

}

Comments

अक्सर आप क्लास में सिर्फ [Serializable] जोड़कर दूर हो सकते हैं।

— हॉलग्रिम

यदि आप सीरियल करने के लिए अतिरिक्त क्षेत्र रखते हैं, तो हॉलग्रिम जोड़ना [Serializable] पर्याप्त नहीं है।

— जो

नायब: "सामान्य तौर पर इस कंस्ट्रक्टर को संरक्षित किया जाना चाहिए यदि वर्ग को सील नहीं किया गया है" - इसलिए आपके उदाहरण में क्रमिक निर्माण को संरक्षित किया जाना चाहिए (या, शायद अधिक उचित रूप से, वर्ग को सील कर दिया जाना चाहिए जब तक कि वंशानुक्रम विशेष रूप से आवश्यक न हो)। उसके अलावा, अच्छा काम!

— डैनियल फार्चूनोव

इसमें दो अन्य गलतियाँ: [सीरियल करने योग्य] विशेषता अनिवार्य है अन्यथा क्रमबद्धता विफल हो जाती है; GetObjectData आधार के माध्यम से कॉल करना होगा। GetObjectData

— डैनियल Fortunov

Answer 3

ISerializable लागू करें, और ऐसा करने के लिए सामान्य पैटर्न का पालन करें।

आपको [Serializable] विशेषता के साथ वर्ग को टैग करने की आवश्यकता है, और उस इंटरफ़ेस के लिए समर्थन जोड़ें, और निहित निर्माणकर्ता को भी जोड़ें (उस पृष्ठ पर वर्णित, एक निर्माणकर्ता की खोज करें )। आप पाठ के नीचे कोड में इसके कार्यान्वयन का एक उदाहरण देख सकते हैं।

Answer 4

ऊपर सही उत्तरों को जोड़ने के लिए, मुझे पता चला कि मैं अगर मैं में मेरे कस्टम गुण की दुकान इस कस्टम क्रमांकन कोई काम कर से बचने कर सकते Dataसंग्रह काException कक्षा ।

उदाहरण के लिए:

[Serializable]
public class JsonReadException : Exception
{
    // ...

    public string JsonFilePath
    {
        get { return Data[@"_jsonFilePath"] as string; }
        private set { Data[@"_jsonFilePath"] = value; }
    }

    public string Json
    {
        get { return Data[@"_json"] as string; }
        private set { Data[@"_json"] = value; }
    }

    // ...
}

संभवतः यह डैनियल द्वारा प्रदान किए गए समाधान की तुलना में प्रदर्शन के मामले में कम कुशल है और शायद केवल "इंटीग्रल" प्रकारों के लिए काम करता है जैसे तार और पूर्णांक और इसी तरह।

फिर भी यह मेरे लिए बहुत आसान और बहुत समझने योग्य था।

Comments

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

— क्रिस्टोफर किंग

वाह धन्यवाद। जब भी एक अपवाद का उपयोग करके throw;इसे पुनः निर्धारित किया गया और मैंने इसे ठीक किया, मैंने अपने सभी कस्टम जोड़े गए चर को बेतरतीब ढंग से खो दिया।

— Nyerguds

@ChristopherKing आपको कुंजियों को जानने की आवश्यकता क्यों होगी? वे गेट्टर में हार्डकोडेड हैं।

— Nyerguds

Answer 5

MSDN पर एरिक गुनरसन का एक उत्कृष्ट लेख "द टेम्पर्डेड अपवाद" हुआ करता था, लेकिन लगता है कि इसे खींच लिया गया है। URL था:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp08162001.asp

आयुष्मान का जवाब सही है, अधिक जानकारी यहाँ:

http://msdn.microsoft.com/en-us/library/ms229064.aspx

मैं गैर-धारावाहिक सदस्यों के साथ एक अपवाद के लिए किसी भी उपयोग के मामले के बारे में नहीं सोच सकता, लेकिन यदि आप गेटऑबजेक्टडाटा में उन्हें सीरियलाइज़ / डिस्क्रिअलाइज़ करने के प्रयास से बचते हैं और डिसेरिज़लाइज़ेशन कंस्ट्रक्टर आपको ठीक होना चाहिए। इसके अलावा उन्हें [NonSerialized] विशेषता के साथ चिह्नित करें, और कुछ की तुलना में प्रलेखन के रूप में अधिक, क्योंकि आप क्रमबद्धता को स्वयं लागू कर रहे हैं।

Answer 6

[सीरियल] के साथ वर्ग को चिह्नित करें, हालांकि मुझे यकीन नहीं है कि धारावाहिक द्वारा एक IList सदस्य को कितनी अच्छी तरह से संभाला जाएगा।

संपादित करें

नीचे दी गई पोस्ट सही है, क्योंकि आपके कस्टम अपवाद में कंस्ट्रक्टर है जो पैरामीटर लेता है, आपको ISerializable को लागू करना होगा।

यदि आपने एक डिफ़ॉल्ट कंस्ट्रक्टर का उपयोग किया है और दो कस्टम सदस्यों को गेटटर / सेटर गुणों के साथ उजागर किया है, तो आप केवल विशेषता सेट करने के साथ दूर हो सकते हैं।

Answer 7

मुझे यह सोचना होगा कि अपवाद को क्रमबद्ध करना एक मजबूत संकेत है कि आप किसी चीज़ के लिए गलत दृष्टिकोण अपना रहे हैं। यहाँ अंतिम लक्ष्य क्या है? यदि आप दो प्रक्रियाओं के बीच या एक ही प्रक्रिया के अलग-अलग रन के बीच अपवाद को पार कर रहे हैं, तो अपवाद के अधिकांश गुण अन्य प्रक्रिया में वैसे भी मान्य नहीं होंगे।

यह संभवतः उस स्थिति की जानकारी निकालने के लिए अधिक समझदार होगा जिसे आप कैच () स्टेटमेंट में चाहते हैं, और जो संग्रह करते हैं।

Comments

डाउनवोट - Microsoft दिशानिर्देश राज्य के अपवादों को क्रमिक रूप से msdn.microsoft.com/en-us/library/ms229064.aspx होना चाहिए, इसलिए उन्हें एक एपोमेनियन सीमा के पार फेंका जा सकता है, जैसे कि रीमोटिंग का उपयोग करना।

— जो