D
dbeavon
Guest
I opened a support call with Progress about the messages in the logs which alert us to mysterious and unexplainable problems (ie. "Cannot throw or return error/stop object to remote client because..."). Tech support has agreed that the only good way to track down the source of an error is to turn on the 4GLTrace for a while. The challenge in doing that is that there isn't a way to change the PASOE logging level on the fly. So it requires a brief outage (to stop and restart the instance) in order for the change to take effect. That isn't the end of the world. But it involves a lot of steps, just to find some additional details about an unexpected error. Here is the KB : knowledgebase.progress.com/.../Tracking-down-the-root-cause-of-error-14438 I should point out that we are already pretty reliable in our exception handling. We regularly remember to put CATCH blocks in our entry-level.p programs for PASOE, and we use those blocks to convert the ABL error types and send them back to the openclient. (We have to send errors back to the .Net openclient using the legacy statement, "RETURN ERROR CH-error." ). The only gotcha is that these CATCH statements normally limit themselves to the application error type, "Progress.Lang.AppError" (and to types that inherit from that). So if there is an error of an unexpected internal type (eg. Progress.Lang.ProError or similar) then those will be the ones that will escape. They are things that come up for reasons that may not have anything to do with our own business logic.
Continue reading...
Continue reading...