title: Serializing Exception to be throwable
body: <p>While I realize there is a similar question (<a href="https://stackoverflow.com/questions/486460/how-to-serialize-an-exception-object-in-c">How to serialize an Exception object in C#?</a>), and though the answers on that page were helpful, they didn't exactly solve the problem or answer the question posed.</p>
  <p>I believe the question was how to serialize the object to allow it to be reconstructed (deserialized) into the same object. I've attempted to use the solution given by <a href="https://stackoverflow.com/questions/486460/how-to-serialize-an-exception-object-in-c/486589#486589">davogones</a> and <a href="https://stackoverflow.com/questions/486460/how-to-serialize-an-exception-object-in-c/2608871#2608871">Antony Booth</a>, but without adding the <code>System.Exception</code> base class on the consuming side (as in: <code>SerializationException: Exception</code>), it is impossible to use these types (by themselves) as actual exception objects that can be thrown.</p>
  <p>Before I continue, let me explain that last statement. I've tried to use <a href="https://stackoverflow.com/questions/486460/how-to-serialize-an-exception-object-in-c/2608871#2608871">Antony Booth's solution</a> in a web service (the service contains the definition for the serializable object) in an attempt to have all consumers use the same exception (hopefully creating a reusable serializable exception type instead of recreating it all over).</p>
  <p>Unfortunately, since neither of the types explicitly derive from <code>System.Exception</code>, you cannot <code>throw</code> them, which would obviously be useful. Like I mentioned above, it does seem that adding <code>: Exception</code> to the type class definition on the consuming side allows the object to be thrown, but that requires editing auto-generated WSDL/web service code, which seems intuitively like a bad/non-maintainable practice to me (correct me if I'm wrong).</p>
  <p>My first question is, again, is it possible to serialize <code>System.Exception</code> or to create a derived type that can be serialized, and if it is possible, how would one go about doing such? I should mention that I've looked at what seems the official way to <a href="http://msdn.microsoft.com/en-us/library/system.exception.getobjectdata.aspx" rel="noreferrer">reconstitute the <code>Exception</code> object</a>, but I'm afraid I don't understand it very well.</p>
  <p>My second question is about the architecture of <code>System.Exception</code> itself. What I would like to know is why the <code>System.Exception</code> type is marked as <code>[Serializable]</code> when it has been documented and apparently designed to disallow you from serializing it properly (at least with XML) because it's <code>Data</code> object implements <code>IDictionary</code>?</p>
  <p>From <a href="http://msdn.microsoft.com/en-us/library/ms950721" rel="noreferrer">MSDN:</a></p>
  <blockquote>
  <p><strong>Q: Why can't I serialize hashtables?</strong></p>
  <p><strong>A: The XmlSerializer cannot process classes implementing the IDictionary interface. This was partly due to schedule constraints and partly due to the fact that a hashtable does not have a counterpart in the XSD type system. The only solution is to implement a custom hashtable that does not implement the IDictionary interface.</strong></p>
  </blockquote>
  <p>Given that XML is becoming (if not already is) a new standard for data transportation (officially recommended by Microsoft, nonetheless), it seems absurdly stupid to not allow the only object type in .NET that can be thrown to not be XML-serializable.</p>
  <p>I look forward to hearing some thoughts from all the SO'rs (especially since this is my first post).</p>
  <p>If you've got questions or need clarification, please don't hesitate to let me know.</p>
  <hr />
  <p>Note: I just found <a href="https://stackoverflow.com/questions/390051/in-c-how-can-i-serialize-system-exception-net-cf-2-0">this SO post</a>, which seems to answer a few questions, but I guess I'd like to take my own whack at it. let me know if it's too close to a duplicate, though.</p>