That code is incorrect though.
The way you know success/fail is whether Error is null. It doesn't matter what Object is if Error != null.
In fact, the Microsoft implementation throws an exception if you try to access e.Object when e.Error != null, and I probably should have done the same thing...
You know I started that way... and somewhere along the line I
switched to doing both checks.
I think now that it was because of an earlier issue with the
CSLA DataProvider in SL (maybe when it was firing DataChanged twice back in the
day) or something but I'm sure I was having an issue where I needed to check
both. I then switched away from the DataProvider and starting just
managing my own async calls via the DataPortal and then of course it just
mindlessly propagated.
I'll put my code back to just check error then but it would be
nice to have the re-assurance of the MS implementation and if I find a null
Object I'll be certain to run it down.
Would that make sense as well in the DataChanged?
While my earlier request is not such a big deal now it might
still be nice to put in a straight bool for success vs. !=null vs. ==
null. If you don't want to then that is fine, I'll take Johnny Bee's
advice and plug it in that way.
Thanks for the clarification.
From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: September-17-09 8:50 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] Request for DataPortalResult Event Arg
That code is incorrect though.
The way you know success/fail is whether Error is null. It doesn't matter
what Object is if Error != null.
In fact, the Microsoft implementation throws an exception if you try to
access e.Object when e.Error != null, and I probably should have done the same
thing...
Copyright (c) Marimer LLC