Why should I always make my Exceptions [serializable]? (.NET)

Question

Referring to What is the correct way to make a custom .NET Exception serializable?
and Are all .NET Exceptions serializable? ...

Why should my exceptions be serializable?
Someone said "it can be considered a bug" if a custom exception defined by a third party library is not serializable. Why?

Why are exceptions different than other classes in this regard?

Rosenbaum

Answer 1

Because your exceptions may need to be marshalled between different AppDomains and if they aren't (properly) serializable you will lose precious debugging information. Unlike other classes, you won't have control over whether your exception will be marshalled -- it will.

---

When I mean "you won't have control" I mean that classes you create generally have a finite space of existence and the existence is well known. If it's a return value and someone tries to call it in a different AppDomain (or on a different machine) they will get a fault and can just say "Don't use it that way." The caller knows they have to convert it into a type that can be serialized (by wrapping the method call). However since exceptions are bubbled up to the very top if not caught they can transcend AppDomain boundaries you didn't even know you had. Your custom application exception 20 levels deep in a different AppDomain might be the exception reported at Main() and nothing along the way is going to convert it into a serializable exception for you.

Pressmark

Can you think of a specific situation/example in which this could actually happen? – Darmstadt

@Sam: NUnit will create one or more separate AppDomains by default, in order to isolate your code from the NUnit runner itself, and it is reasonable to expect that other unit test frameworks do the same. – Hatshepsut

Answer 2

In addition to Talljoe's answer, your exceptions may be passed across Web Services as well, in this case the exception needs to be serializable/deserializable so it can be turned into XML and transmitted by the Web Service

Boiling

Jeffrey: you're almost correct. When an exception is "sent" over a web service, not all is necessarily being serialized. It's actually being converted into a SOAP Fault, so full fidelity is not required. Also, the XML Serializer used in the old ASMX services pays little or no attention to [Serializable]. – Historiography

Answer 3

I think that the default for all classes should be Serializable unless they contain a class that is explicitly not serializable. It's annoying to not be able to transfer a class just because some designer didn't think about it.

The same thing with "Final", all variables should be "Final" by default unless you specifically say that they are "Mutable".

Also, I'm not sure it makes sense to have a variable that is not private.

Oh well, need to design my own language.

But the answer is, you don't know how your exception will be used and they are assumed to be able to be thrown across remote calls.

Arthro

@Bill: Alternatively, the designer did think about it, but decided against supporting serialization. For instance, how would use serialize a class that holds handles to native resources, or even just open streams? – Historiography

Exceptions shouldn't need to do that. Also, the 3 classes I've run into and wanted to serialize in the last month (including an exception) didn't have any such restrictions. It was simply not spec'd that way by the committee that designed the unchangeable API – Arthro

Oh, and as for my serializable by default suggestion, if you had those conditions, the resources would be marked "unserializable" which would chain up to your class making it unserializable unless you tagged them as "transient", so it would work fine--better than the current system. – Arthro

Interesting opinions. I understand Exceptions are intended to be remoted, which requires [serializable]. But what about the 2nd part of the Q: why are exceptions different from any other class? wrt [serializable]? The class that throws the exception is not serializable, and no one seems to be up-in-arms about that. – Rosenbaum

The class that throws the exception has a reasonable expectation that it will not be made remote (Since I just implemented a huge stinking pile of RMI, I can tell you that this is not ALWAYS true, but in general it is). With an exception, you would have to know all the classes above you to know this was true. By making an unchecked exception serializable you could randomly break remote code in strange ways with very little ability to figure out what happened (on the client side, it might just look like your call never returns--ever. I had to chase one of these down, it's pretty WTF). – Arthro

Answer 4

I have a differing opinion than the existing answers. The default behavior should be to do nothing unless you need to do it. It is not simply one line of code to make an exception serializable.

My organization has never had a need to code properly serializable exceptions. So, we don't. No need for more boilerplate.

Perpetuate

please do not keep re-adding the same remarks about if/how/when the question was closed, they do not belong in answers. – Ferroconcrete

Answer 5

Another place where objects required to be serializable is Asp.Net Session. We store last exception in Session and not serializable exceptions needs extra translation to store their details as serializable( specifying original exception as inner doesn't help)

Bozen

This sounds like a reason why exceptions need to be sdrializable in your use case, but it doesn't really answer the general question. – Religiose

@stakx, when you right the code, you should consider different use cases, where it can be used – Bozen