It was working fine until a coworker ran a SQL query that changed an int field (which maps to an Enum in our code) to an invalid value on several records in a common test database a few of us were pointing to.
All of the sudden we were getting a FaultException (I can't remember the exact error - but it was one of those unrelated ones that mask the real exception message that caused the problem to begin with.) while trying to load a graph.
Further investigation revealed that our asynchronous calls to the WCF service client were retrying the same call three times and coming back with a failure. Stepping down deeper into the code, we saw that our resultset seemed to be coming back fine from our data layer, leaving us wondering why it was behaving so strange.
My coworker put a breakpoint where our data layer returns the IEnumerable
Only a single attempt was made on the service instead of three and the data was received fine by the application... However, when we reverted to allow the regular resultset through, it again made three attempts and returned the exception.
On the next run, we decided to look at the resultset closer in the QuickWatch window. We didn't look carefully enough because everything looked correct... so we started removing one object at a time until we could prove that the culprit was corrupt data in our resultset.
Finally we expanded two objects in our collection at the same time in the QuickWatch window and started comparing. We noticed that one instance's enum property was retuning the name of the assigned enum and another showed an integer value.
After asking why that would happen, it dawned on me that it must be an invalid enum value and therefore couldn't resolve to a name when ToString() was called. I assume to fail gracefully, Microsoft had their Enum.ToString() try to do name first and just fall back to the value of the Enum's base type if it couldn't resolve the name, rather than throwing an Exception.
Examining the implementation of the enum quickly confirmed the suspicion. After probing other coworkers, we discovered the erroneous query that had been run against the database. :)
I assume what happens is an exception occurs when the WCF tries to serialize the object to send across the boundary... but the exception is swallowed up and the Fault Exception with the less-than-helpful error message is returned to the consumer of the service.
Moral of the story: Be careful when using Enums that map to data in your database. Make sure they always match the allowed values in the database (which is easy to do if you have look-up tables and use an ORM (like PLINQO, etc.) to generate the enums for you.
Also, if you use "switch" statements in your code on the enum value, make sure your default case handles an invalid enum value scenario. For instance, you've made a switch statement that contains a case block for all valid enum values. Your default case can throw an ArgumentOutOfRangeException so you can quickly detect when something like that happens.
This will be harder to detect in scenarios like the one I described above, because the code is still "valid" at compile and runtime until the sucker is serialized. I don't know what the best practice solution is for that scenario, but I do know I want a better FaultException passed to me if serialization breaks before being passed from the WCF service.
Guess I have my work cut out for me tomorrow.
For those like me that have a hard time visualizing what I'm talking about... here's a contrived example.
public enum ReportType
{
Html = 1,
Excel = 2,
Pdf = 3
}
The query to the database changed the offending records to 0, 4 or some other number that wasn't the valid values. (Incidentally, my coworker really meant to change another int field's value... but ended up typing the wrong column name.) Too funny.
And now you know... go forth and make sure you aren't bit by this problem.
No comments:
Post a Comment