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

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.

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].

John Saunders 2009-07-01 00:27:56

@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?

John Saunders 2009-07-01 00:58:46

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

Bill K 2009-07-01 01:07:13

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.

Bill K 2009-07-01 01:09:22

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.

Cheeso 2009-07-01 08:17:52

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).

Bill K 2009-07-01 17:22:23

ansaurus

tags:

views:

answers:

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

related questions