L
Laura Stern
Guest
Yes indeed, putting the sting into the Return value was done to be equivalent with doing RETURN ERROR string. And that is “natural” when returning an error to an open client that does not yet have the capacity to deal with anything else. But in a more modern application, the “natural” thing to do is to set the string as an error message. It is not odd at all that the Progress.Lang.Error interface does not give you the ability to retrieve the Return Value. Progress.Lang.Error Is an interface that is shared by all the error objects, and most of them, all but AppError, do not have a Return Value. Therefore the interface doesn’t have it. And if a P.L.Error is caught you can get the Return Value by checking if the type of the instance is an AppError. If it is, you can cast it to an AppError and access the ReturnValue property. That is the way OO works. However, I do agree that it would be good if ToString() gave you all the error messages as a concatenation string, and for an AppError instance, the ReturnValue would be included as well. That way, all you need is ToString, and regardless of what type you’ve caught, it will give you what you want. Regarding PASOE giving different information for different error types, I was not aware of that. I suspect it is the difference between RETURN ERROR vs throwing an error object. But in general, the error handling model was designed to interoperate between the older and newer models in one coherent, integrated fashion. Therefore, it is doing this, I would consider it a bug.
Continue reading...
Continue reading...