L
Laura Stern
Guest
Not mysterious. These are different statements doing 2 different things. RETURN ERROR raises an error and sets RETURN-VALUE. Whereas when an AppError is thrown it raises error and there is an error object available to be caught. The error object can have a ReturnValue set in it, or not, an error message set, or not, and possibly can have other properties if it is a custom AppError. Having said, that, when RETURN ERROR happens, internally, the AVM usually makes an AppError automatically, setting the ReturnValue property with the string so that if there is a CATCH statement above, this can be caught like any other thrown error. And no, you can't tell if this came from the application itself or was manufactured by the AVM. Don't see a reason for the app to know that. But when RETURN ERROR happens at the top-level procedure of an AppServer and the client is a .NET client, there is no point in making an error object because there's nothing we can do with it. As I had said in a previous post, the OpenClient product was not upgraded to be able to handle error objects, so it still uses the old mechanism (though in 12.0, Java OpenClients have been modified to get error information from a thrown error object). So RETURN ERROR works the way it always did. But if an error is thrown, we say that we cannot do it because the mechanism for doing that is not implemented. Pretty straight forward. I believe I had suggested that you log a bug: The AVM should log the actual error message, if there is one, when you get error 14438. I.e., If we can't throw the error to the client, we should at least get the error information in the log file. So please do that if you haven't already.
Continue reading...
Continue reading...