Can someone help with meaning from VFP Help for ComReturnError

[cfsjohn]

VFP help for ComReturnError() says:
COMRETURNERROR( ) Function
Executing COMRETURNERROR( ) places the specified text in the COM exception structure, aborts executing the current method, and returns control to the client. The Automation server remains in memory and the client can call more Automation server methods.

I am confused about what "aborts executing the current method, and returns control to the client" means.

My web service is a COM server. Let's call it "ITFBO". It calls other COM servers.
So a hit to the "server" comes in.
The appropriate endpoint is executed. An endpoint is just a method. Let's say the endpoint is "GetBalance()".
The endpoint method calls a method in a different COM server to actually do what is necessary to get the balance. Let's call this COM server "VFEITFBO". The method that gets called is "VFEGetBalance()".
VFEITFBO has an on error method.
If any error occurs, ComReturnError gets executed.
So, an error occurs while executing VFEITFBO's VFEGetBalance method. The ONERROR method is called and ComReturnError gets executed.
Can you tell me exectly what happens? Where does code exection resume? Does VFEITFBO continue to run?

Thanks,
John

 

[Joe Crescenzi]

It should follow the hierarchy and each layer will be able to send messages upwards one level.

So, if you catch an error and push your own message into the exception, whatever function called that function will have access to that message.

For example, a COM server called TOP calls a COM server called MIDDLE, which calls a COM server called BOTTOM.

If an error is caught in BOTTOM, MIDDLE should be able to see it, then you can decide whether MIDDLE should take action, or relay yet another error to TOP

 

[Chriss Miller]

If a server uses another server, it becomes a client of that other server.

So COMRETURNERROR will return to the ITFBO. It does not return to the GetBalance, though, because it causes an OLE error and that causes an error routine in the ITFBO client (that's technically also a COM server, but is a client because it calls the VFEGetBalance method in the VFEITFBO server.

Does that make anything clearer?

I'd explain it inversely, starting from an error happening in a VFP application, if that error happens in a COM (automation) Server, no matter if that's a VFP COM Server or any COM Server like Word.Application, you get an error number 1427 or 1429, as those are the OLE error numbers. And an AERROR call then populates the array with some informations from the OLE server, if the OLE server provides them. COMRETURNERROR is a function that allows you to do so. So unlike so many OLE errors that leave you with no further information than that it was an OLE error 1427 or 1429 you can pass on informations.

They don't get back to the calling method, they get back into the error handler of the client, which in your situation is the ITFBO COM Server. If you don't have an ON ERROR routine there, it gets lost, if your ITFBO COM server has an ON ERROR routine that itself is making a COMRETURNERROR call you would throw an error in the actual client that called GetBalance(), though, so this would cascade the error triggering.

So your error handling should handle errors 1427 or 1429 specifically. Within a COM Server this does mean the error actually happened in another COM Server and you may or may not want to forward that with COMRETURNERROR, too. If any normal error happens within a COM Server the error handling of errors other than 1427 and 1429 can and should definitely use COMRETURNERROR to help the client get it, unless you have error handling code that actually handles the error in the sense of resolving it and continuing, which would mean you don't need a client further up tha call chain to get informed about it, as you actually resolve it.

And to make this even more complicated, COMRETURNERROR of course can also be used in a COM Server to add this error information to the client outside of the COM Servers general error handlling, i.e. you can trigger an error in the client.

What COMRETURNERROR is not is returning an error instead of the usual return value of a method. It's not just a simple RETURN mechanism, it's a mechanism to add to the error information structure and it causes an error in the client, whether the client is a normal non COM Server client or COM server itself doesn't matter. Just the caller process.

All in all it means that you can still have an all purpose error handling routine you can use in clients, in COM Servers, also if they use further COM Servers as clients of them and also on the second level. It makes always sense to look into what error number errors have, to know whether the current process/thread is a COM Server to make use of COMRETURNERROR in case you don't resolve the error and continue.

 

[cfsjohn]

Joe and Chriss, The parts about everything moving up the hierarchy is logical and I concur.

It should follow the hierarchy and each layer will be able to send messages upwards one level.

So, if you catch an error and push your own message into the exception, whatever function called that function will have access to that message.

For example, a COM server called TOP calls a COM server called MIDDLE, which calls a COM server called BOTTOM.

If an error is caught in BOTTOM, MIDDLE should be able to see it, then you can decide whether MIDDLE should take action, or relay yet another error to TOP

Joe, Using your scenario, when the error is caught in BOTTOM and COMErrorReturn gets executed, the error routine in MIDDLE (assuming there is one), would automatically get executed and it would need to do something about dealing with the error. Am I understanding correctly?