I think I found a bug in Csla 4.5.501.
You can recreate it by creating a simple editable business object and a business rule where the rule ctor throws an exception.
In my case, I was throwing an ArgumentException if one of the propertyInfo.Type != typeof(string) as the rule only works against string properties.
The end result was that Csla from the SimpleDataPortal was throwing a NullReferenceException which was not the exception actually thrown by the ctor prior to the call getting to my DP_F method.. I'm calling this a bug because it took me a few hours to figure out what was going on. I would have expected to see my ArgumentException somewhere, not a NRE from an anonymous' classes MoveNext method. :-)
For my coding preference I always use generic constraints like
PropertyInfo<string> propertyName
when a rule only works on one type (here string) and this way I can define the contract and not bother with type checking the arguments.
The challenge here is that rules is registrered in the to <bo> constructor on the first time you create the <bo> and CSLA will cleanup the "already registered" rules for the type in the internal Exception handler. Not sure where this is called so must check out in th code. But you would making more solid code if you use generic constraints on the parameters - when needed.
I believe any exception thrown in the ctor causes this, but I can verify that tomorrow. If this is the case the exact check I'm doing is irrelevant. Mistakes in calling the ctor shouldn't cost a developer hours determining why they are getting a NFE from deep within Csla. I thought the purpose of having the interface was to make unit testing easier; its shown that way in the eBooks and explicitly pointed out that the rules take the interface.
Copyright (c) Marimer LLC