16 November, 2007

on throwing errors

not too long ago i spent quite a few days trying to solve what was a really easy bug.

after moving a class from one assembly to another, one of my biztalk orchestrations started throwing a runtime error saying that it couldn't serialize an instance of a XmlDocument.

because the runtime error did not return a stack trace, i was very confused: even though XmlDocument truly is not serialiazable, biztalk is able to dehydrate the contents of a XmlDocument instance by getting the XmlDocument's outerxml and storing it; upon rehydration, the XmlDocument is loaded with the saved string.

after a few days of thinking about this problem, I realized that the error was not coming from the orchestration's instance of XmlDocument, but instead from a class that held and instance of XmlDocument and which the orchestration was using.

i simply marked the XmlDocument variable declaration with [NonSerializable] and all the problems went away.

i mention all of this because if had just gotten the stack trace, all the hassle I went through could have been avoided.

i've noticed that the errors i throw are usually not very descriptive, because i understand the code and i know what's going on. however, i've also noticed that when co-workers get exception from my code, it's not clear to them what the error means.

thus the importance of throwing very specific and very clear error messages; even if they're a little verbose. and outsider needs to understand the context of what's going on in order to be able to understand and solve problems.


lewisrw00 said...

So, did you end up having to put the call to your helper class within an atomic scope (so that BizTalk wouldn't complain about the NonSerializable attribute)?

Post a Comment