>Back in my VFP days when I was writing COM DLL's I would have an internal Validate method that would perform validation on required items, and if something was not right, I would set an ErrorLevel property to a unique error number. Then the calling class/form
>would check the property to see if was > 0. Problem is that this couples the DLL to the class.
>
>So, what I'd really like is some way of my class notifying the calling class that the properties are not correct.

If you think about it the coupling has to exist:
If you set a property the UI has to know to check it.
If you raise an exception then the UI needs to catch it in a meaningful manner.
If you use an event then the UI has to be aware of the need to wire it up...

The advantage of using an exception of course is that if it's unhandled it *can't* be ignored.

There's an idea in WPF that could be adapted: Have any BO that reports validation errors implement the same interface (even something as simple as a string describing the problem). The UI control can then check the class to which it is bound and, if it implements the interface, check the relevant properties and act accordingly....

I think this is the similar to Bonnie's suggestion for datasets but OK for data objects in general.....



>
>
>
>
>>>>FWIW my vote would be against throwing exceptions for invalid or missing data.....
>>>
>>>Why not? Inquring minds wanna know....
>>
>>Exceptions are expensive. By that I mean that it takes a lot of time to throw/catch them. They probably should not be used for something like validating data. If you can determine that there's a problem by checking stuff, then you should do it. Exceptions are more for errors that are not "checkable" easily any other way. That's a rather simplistic way of looking at it, but I think it's a good rule of thumb.
>>
>>~~Bonnie