Jerry Dennany's Occasional Clue

Sorry for the pain. :)

Ok, I stand corrected. Only one of the two people I know that reads my blog knows better ;-)

If you'd like to expand your readership to the double digits, I would recommend explaining the need/benifit to a serializable exception.

That was meant to be tounge-in-cheek. I must have left off the ";-)"

;-)

Do *NOT* derive your exceptions from ApplicationException.

http://weblogs.asp.net/dotnetrolando/archive/2005/04/11/399846.aspx

Note to Brad: one more evidence that .net docs are taking developers to the wrong conclusion.

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

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.

FYI: This is the source of the "don't derive from ApplicationException" note. msdn.microsoft.com/.../ms229064.aspx

BUT, it also points out that decorating the custom exception type declaration with [serializable] is not enough. You must also provide, at least, a ctor that accepts args as (SerializationInfo, StreamingContext) .

See also, winterdom.com/.../makeexceptionclassesserializable