Mark custom .NET Exceptions as [Serializable]

Tuesday, April 26, 2005

.NET

The two people that read my blog (besides my sister) know this already, but if you author a class library, please mark all classes deriving from Exception (or even better, ApplicationException) as [Serializable]. If I am using your library on the other side of a remoting channel, non-Serializable exceptions will cause me much heartache.

With Affection,

Your Customer.

7 Comments

Sorry for the pain. :)

Paul Wilson - Tuesday, April 26, 2005 8:31:00 PM
Ok, I stand corrected. Only one of the two people I know that reads my blog knows better ;-)

Jerry Dennany - Tuesday, April 26, 2005 8:52:00 PM
If you'd like to expand your readership to the double digits, I would recommend explaining the need/benifit to a serializable exception.

Alex Papadimoulis - Tuesday, April 26, 2005 9:10:00 PM
That was meant to be tounge-in-cheek. I must have left off the ";-)"

;-)

Alex Papadimoulis - Tuesday, April 26, 2005 9:10:00 PM
Rolando -

There is nothing inherently 'evil' about deriving from ApplicationException. It's an extra level of indirection, but it's all merely a matter of preference.

There are a lot of other things in the Framework that need to be fixed before this.

Jerry Dennany - Tuesday, April 26, 2005 9:42:00 PM
Jerry:

in your post you mention that it's *better* to derive from ApplicationException but according to the .net team: "... it only adds unnecessary depth to the hierarchy". So probably is not evil but certainly is not better.

Rolando - Tuesday, April 26, 2005 11:05:00 PM
Alex you missed the word remoting. I had to read the post twice before getting it :)

...don't derive from ApplicationException... gosh I cannot keep up. I must read more blogs, sleep is overrated anyway.

Paul Lockwood - Wednesday, April 27, 2005 12:24:00 AM

Comments have been disabled for this content.