Hi Simon,

If you are referring to documentation for AutoOpen and OpenTables method then I agree, there is a doc BUG there. But, if you are referring to the fact that failure of CursorFill/CurssorAttach is not trappable by an outer try catch, I have to disagree. The help says it clear:

Return Values
Logical data type. CursorFill returns True (.T.) if the cursor 
is created successfully and False (.F.) if not created successfully. 

Note   If CursorFill returns False (.F.), the cursor is discarded. 
In this case, the BeforeCursorClose and AfterCursorClose events do not
occur. To retrieve error information when CursorFill returns False (.F.),
you must call the AERROR( ) function because the ON ERROR command does 
not execute.

Return Values
Logical data type. CursorAttach returns True (.T.) if the cursor is 
attached successfully and False (.F.) if attachment fails.

It says that in case of failure, those functions return .F.. For me, it automatically implies that error is not raised and exception is not thrown simply because, otherwise, there is no point of returning .F., the code would be jumped over. There are other functions in VFP that behave the same way, it is not something new brought by CursorAdapter.

I agree, VFP help is not perfect, but it is not useless. For CursorFill method, it even says that ON ERROR is not triggered. It doesn't say anything about TRY/CATCH, but they sort of replace one another.

Of course, it wouldn't hurt to add TRY/CATCH there and replicate this information for all similar methods. I will make sure it is done. Thank you, we appreciate your feedback.

Simon, if you want those methods to raise an error or throw an exception, it is all in your hands, you are overriding them any way.

Thanks,
Aleksey.

P.S. I see that you haven't read my message #822450. I am pretty sure, I checked CC check box for you. May be something went wrong and you didn't receive notification. Please take a look when you have time. Thanks again.


>Hi Aleksey
>
>I do not remember anything in the doucmentation telling me about the details of error handling that you just mentioned. If I had known that I would have constructed my class differently. I assumed the Try/Catch would catch all errors. Now I know that it will not I will build my class appropriately.
>
>I am not blaming you but there sure does seem to be alot missing in the documentation not only on cursor adapters but on other items as well. I find it aggravating that I have to spend so much time experimenting just to find out how things work.
>
>However, I must say that you have been very helpful in your discussions with me and others regarding cursor adapters.
>
>Thanks
>Simon
>
>
>>>Hi Aleksey
>>>
>>>I have already done something like you suggested below to trap for the condition. However, it raises another question. If an error is reported by AErrors() why was it not trapped by the Try/Catch error handling? I had wrapped my code in the Try/Catch specifically to catch any errors but it never did. So I did not think to use in the Aerrors() functions. It seems that both the Aerrors and Try/Catch should both detect the error.
>>>
>>>This makes me think that there is a bug in the Try/Catch error handling mechanism.
>>>
>>>Simon
>>>
>>
>>Hi Simon,
>>
>>It is difficult to say anything specific without knowing exactly what your code looks like.
>>
>>However, CursorAdapter methods do not raise an error and do not throw an exception in case of failure. They indicate a failure thru output parameter (similar to TABLEUPDATE function) and provide the error information for AERROR function. Any exception/error that happens inside of those methods must be caught by the CursorAdapter and transformed into appropriate return value to indicate the failure. That makes those errors not trappable by outer TRY/CATCH by design.
>>
>>Thanks,
>>Aleksey.
>>
>>