Daniel,

I agree that error handling at the object level can have usefull properties and if identified as such in a cetain case, I'll use this strategy also. This mainly applies to situation where errors can occur that are not due to programming but rahter due to the environment (e.g: USEing tables exclusively).
For all other errors (due to bugs in programming) i'd rather have one global ON ERROR routine and handle it from there.

As you've shown with a OO approach there is still a bit of programming to do, which I generally trying to prevent. Inheritance of the error event is fine, however, you still have to code them for every baseclass or use an interface strategy, which is not my idea of compact and efficient coding.

Personally, (and I agree there can be other viewpoints), I'm very comfortable in having one central ON ERROR routine handling all program errors.

Walter,

>There are a lot of advantages using a good error handling strategy. If you handle errors in a class, you can take advantage of many features that are not easily available with a traditional error handler. For example you can do things like the following on object level:
>
>.lDisplayErrorMessage = .t. && should error messages be displayed?
>.lLogMessages = .t. && log error messages to table/file?
>.lStackMessages = .t. && stack error messages
>?.nLastErrorNo && get error no of last error
>?.lError && has an error occurred
>.lErrorTrap && should the next error be ignored?
>.lDebugMode = .t.
>etc.
>
>Since each object is responsible for error handling, you can now track, manage and handle errors by object.