D
dbeavon
Guest
I think BLOCK-LEVEL ON ERROR UNDO, THROW would work fine in the top level procedures too if all the errors were serializable *and* if my client wasn't the .Net openclient. They would simply be passed along to the ABL client. It would also be a lot less programming effort than putting TRY/CATCH blocks around all the logic in every method of the top-level procedures. However in the case of errors which aren't SERIALIZABLE, or ones that are destined for a .Net, then we see the kind of troubles I've been complaining about. When I talked about how "unhandled" exceptions may "crash" a runtime, I was talking in general about my experience from other technologies (like .Net). The "crash" in the context of PASOE might be analogous to what happens when using the QUIT statement from an ABL session. Ultimately I don't really care if it "crashes" altogether or not, but I do want the escaping error details, because they are not made available to .Net and they are not made available to the PASOE logs. As far as the "generic message" that the .Net open client gets, I mean that it something totally unhelpful (ie. it is basically an exception that says "an error occurred", and is derived from the type Runtime4GLErrorException). This doesn't help identify the underlying cause, any more than the message written to the PASOE logs (ie. "Cannot throw or return error/stop object to remote client because object is not serializable"). >> Just don't use BLOCK-LEVEL ON ERROR UNDO, THROW in the top level procedure. That is just wrong for this .Net Open Client scenario. And that is what is masking what the real error is. If you weren't trying to throw it out of the server, you will see the real error in the log. I realize this is true. As a customer that uses the .Net openclient proxy, we are forced to wrap error handling around all the top-level methods in the top-level procedures. They all use something like this: CATCH v_AppError AS Progress.Lang.AppError : RETURN ERROR (IF v_AppError:ReturnValue <> "" THEN v_AppError:ReturnValue ELSE "Unknown application error in ~"TopLevel~" at line {&LINE-NUMBER}."). END CATCH. CATCH v_ProError AS Progress.Lang.ProError : RETURN ERROR "Yet another unknown error: ". + v_ProError:GetMessage(1). END CATCH. But if that repetitive code is ever omitted , then we get the kind of troubles I've been complaining about. Similarly if we remember to have a CATCH block for Progress.Lang.AppError but not for another type of error (Progress.Lang.ProError or Pro.Lang.Error) then we get the kind of troubles I'm complaining about. This type of issue is rare and troublesome considering that the PASOE runtime doesn't point us to the root source, or give any of the error or the stack detail. If there was a way to change the configuration of agent logging on the fly then I might consider turning on 4GLTrace for the day, but this doesn't seem possible either without restarting the whole PASOE instance.
Continue reading...
Continue reading...