>>>>>>>>>I'm creating a set of classes to handle data:
>>>>>>>>>
>>>>>>>>>

>>>>>>>>>class CompanyInfo : DataRecordBase
>>>>>>>>>{
>>>>>>>>>    private string _CompanyName = "";
>>>>>>>>>    public string CompanyName
>>>>>>>>>    {
>>>>>>>>>        get { return _CompanyName; }
>>>>>>>>>        set { _CompanyName = value; }
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>    public override bool SaveChanges()
>>>>>>>>>    {
>>>>>>>>>      if(Validate())
>>>>>>>>>      {
>>>>>>>>>         // Code here to save
>>>>>>>>>      }
>>>>>>>>>    }
>>>>>>>>>    public override void Load()
>>>>>>>>>    {
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>    private bool Validate()
>>>>>>>>>    {
>>>>>>>>>        bool bRetVal = true;
>>>>>>>>>
>>>>>>>>>        if (_CompanyName == "")
>>>>>>>>>        {
>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>>        return bRetVal;
>>>>>>>>>    }
>>>>>>>>>}
>>>>>>>>>

>>>>>>>>>
>>>>>>>>>They are all based off the abstract class DataRecordBase. The question is this - If the Validate method returns false, because a property is not complete, what should happen? I don't want to raise an exception?
>>>>>>>>>
>>>>>>>>>Since this is a non-visual class I don't want to pop up a message in this class. I'm thinking that Validate should set a class variable to an appropriate message, and maybe set a public IsValid flag to false.
>>>>>>>>>
>>>>>>>>>Then, in the form or class that uses it, if SaveChanges returns False then I know that the message property would be populated with something like "The Customer Name cannot be empty".
>>>>>>>>
>>>>>>>>I'm never in favour of public variables. You could use an out parameter to pass back the error message (or even an array of error messages) so something like:

>>>>>>>>        public bool SaveChanges(out string msg)
>>>>>>>>        {
>>>>>>>>            if (!Validate())
>>>>>>>>            {
>>>>>>>>                msg = "This went wrong";
>>>>>>>>                return false;
>>>>>>>>            }
>>>>>>>>            else return true; 
>>>>>>>>        }

Called with

string str;
>>>>>>>>            if (!CompanyInfoInstance.SaveChanges(out str))
>>>>>>>>            {
>>>>>>>>                MessageBox.Show(str);
>>>>>>>>            }

BTW, if this is WinForms have you thought of using the ErrorProvider class in the UI?
>>>>>>>>Regards,
>>>>>>>>Viv
>>>>>>>
>>>>>>>I guess I could, but this class just represents a data record. It's not visual. That's why I thought a property defined in the base would work.
>>>>>>
>>>>>>But surely the error has to be surfaced in a visual way eventually - and the UI layer is the obvious (possibly only sensible) place for that?
>>>>>
>>>>>Yes, but this class and those like it are not UI components. They are a data record represented in a class. So when an issues/exception occurs, how do you inform the UI?
>>>>
>>>>You raise an event. Am I missing the basic question of the thread?
>>>>Tim
>>>
>>>Not at all. That was my original idea, but others have been advocating a different error handling approach.
>>
>>IIRC you were considering using a public variable - no mention of an event which, as Tim suggests, is another option. The problem with using an event is the same as using a return value - there's no guarantee that it will be handled. The safest option is to raise an exception (.NET has the ValidationException class just for this purpose) but, of course, it has more overhead.
>>
>>In general terms you could look at the IDataErrorInfo interface - or the use of the Validation Application Block....
>
>This is an area where I admit I have not explored enough but the question about "There is no guarantee that it will be handled" is an interesting one. As the developer of a component, how much responsibility do we have to insure a using application must respond to our events?

I don't see how we can take *any* responsibility (other than documenting the event).

> If I raise an exception and they don't handle that, then have we not just broke there application?
No - we haven't broken it - they have :-}

> If I raise an event and they don't handle it the same thing may occur too. It seems logical to me that we should consider not just the implications but the severity of what caused us to raise an exception or event in the first place.

Agreed. But if not handling the event will result in an exception further down the line then maybe it's preferable to raise a specific exception rather than an event in the first place?

An empty string for instance in a parameter for data retrieval may only need to raise a simple event and return no data. In cases like this, if the expectation is a DataSet, I just return an empty one rather than null so it doesn't blow them up and also raise an event so that if they care to know why they have access to it.

The right solution there would surely depend on the business rules. If an empty string was not acceptable then the solution isn't strong enough....

>Just some of my random thoughts and would be interested in hearing others.

I thought I had a link to an MSDN article on using the ValidationException class but I can't find it. IIRC it implied that using the ValidationException was, in some way, lighter than using other exception classes - though I don't see how that might be?
Regards,
Viv