D
dbeavon
Guest
Thanks for the tips. I was talking about both the client side and the appserver log. One or both of them should have more error details. EG whenever PASOE is going out if its way to print this in the logs ("Cannot throw or return error/stop object to remote client because object is not serializable or client does not support it"). Then at that same time it could at least say which top-level procedure was involved, and the error type, and the -errorstack (if available). Unfortunately we now have BLOCK-LEVEL directives in all our *.p and *.cls. Otherwise Progress ABL error handling behaves in unusual ways (especially for loops that use the default ON ERROR behavior). Without knowing which top-level procedure is failing, it is hard to remove that procedure's BLOCK-LEVEL directive. I suppose we will probably have to shut down the PASOE instance this weekend and enable 4GLTrace logging for the following week. That appears to be the most certain way to find the source of the error (unless the affected user will eventually call us about their error messages that they are probably getting in their application U/I). Thanks for the news about the improved marshalling of errors from PASOE to Java. That is definitely something we'd be interested in for the .Net openclient too. You'd be amazed how hard we have to work to cram the relevant error information into the legacy statement, "RETURN ERROR CH-Error". It can sometimes be a huge chunk of xml or some such thing. Another option can involve storing the error and returning only an identifier... so that the related details can be fetched as a ProDataSet in a subsequent round-trip.
Continue reading...
Continue reading...