>I kind of like the Java model of "throwing an exception". I've been working on an Error (or Exception) object that belongs to the base classes in my framework, i.e. this.oErrorObject. Errors place pertinent information in the error object, which can be queried by calling methods when a method call returns a failure. The advantages are that I can pass this object around where appropriate, either to specific or generic handlers, pass it up the call stack and let someone else worry about what to do with it, or implement a kind of try/catch mechanism by looking for a specific state in the error object.

Thanks for your reply. I find error handling is one of the least disussed topics in technical books. It's good to hear other peoples experience.

I think I know what you mean by exception error handling, but I'm not sure. Here is a simple example of what I think it is:

the classes Error() method has one line: this.HadError = .T.

each method in the class has this at the top:

llRetval = .T.

and this at the end:
if .HadError
.HadError = .F.
llRetVal = .F.
endif
return llRetVal

I like this approach b/c you can write things that come close to never crashing--they just return a false!

>
>As far as the set/get stuff, despite the questionable OOP issues regarding Access/Assign, basically Access/Assign is set/get anyway, so I've been using that a lot. Makes for a lot simpler interfaces to objects. I use set/get when I have to deal with multiple parameters to return a value, like something calculated, or things passed by reference (which I try to avoid).
>
>As far as true and false vs. 0 and 1, in reality with a bit datatype false=0 and 1=true anyway, so I don;t see any reason not to take advantage of VFP's build in boolean datatype since it's easier to say,
>
>IF condition
>
>than
>
>IF condition=1
>
>My 2 cents...
>
>>Yes, I can see the value of putting the error content in a different object. Nice design. Currently, I store the cFirstErrorMsg and cLastErrorMsg as properties of the object, and when I go to reset the object to their default state when they encounter some kind of error--i can do that for all properties except those releated to the error state. Of course, storing an object reference to a collection of cannot be reset either . . . hmmmm, i guess I'll wait to work on this until I really need to worry about stateless objects. (perhaps some type of observer pattern here would work . . .)
>>
>>So, does how will your UI get a value of an object property?
>>
>> lcUIValue = oBiz.cPropValue
>>
>>or
>>
>>lnRetVal = oBiz.GetPropValue( @lcUiValue )
>>
>>or ?
>>
>>Thanks.
>>
>>>Mark ---
>>>
>>>I'm working on a writing up an object scheme that handles this exact problem.
>>>
>>>In general, consider adding a collection property to the object you are calling: Alerts(). Have your UI return 0 if success or -1 if failure. If a failure is indicated, you can always query the obj.Alerts() collection to find out what the error(s) are.
>>>
>>>Obviously, you also need to be heads up in the how you set Alerts, but a really keen way of doing it is to use the new Assign event for all properties in the object to set Alerts and intercept values that violate data or business rules. BTW, you also need to reset the Alerts collection in the object internally...
>>>
>>>
>>>
>>>>I recently learned the C programming standard for method return values:
>>>> 0 if the method completed successfully,
>>>> >0 the method encountered some application error.
>>>>
>>>>I was wondering how people implemented "Get" methods.
>>>>
>>>>You can stick to the approach above and return the appropriate property value in a parameter passed by reference, but this is an awkward interface for the UI.
>>>>
>>>>If you don't use this approach, then how do you tell the UI an error occured? I suppose you could return either the property value or some special value to indicate an error, but this also creates a "muddy" interface for the UI-- for example, the property value could be a different type than your error return value.
>>>>
>>>>Thanks.
>>>>
>>>>- Mark