D
dbeavon
Guest
>> But in a more modern application, the “natural” thing to do is to set the string as an error message I think the constructor of AppError that takes a single character string (and puts it in the ReturnValue) will always remain very popular. The one that also takes a "MessageNumber" parameter seems way too bureaucratic. It seems to imply that we need to maintaining a registry of all possible errors before our programs are allowed to raise any errors. The truth is that programs will always have reasons for failure, whether there is a previously registered "MessageNumber" for it or not. Maybe the constructor that takes a single character should also add a default Message/MessageNumber pair internally (with a default MessageNumber of MaxInteger or -1 or something). >> I suspect it is the difference between RETURN ERROR vs throwing an error object. This is what I was thinking too. It is a good thing that data doesn't print to the agent log except in very limited circumstances. The RETURN ERROR statement is how "openclient" applications expect to receive business logic errors, and these would fill up the agent log very, very quickly because they happen as a matter of course. Peter Judge mentioned this before, but there needs needs to be some way (a method/trigger/event) for us to perform an ABL action based on errors that are "escaping" from an ABL session in PASOE. It should be up to us to determine what type of stuff is interesting enough to write to the PASOE agent logs. (We could be responsible for doing this ourselves via calls to the LOG-MANGER from the escaping-error-action-code.) Currently it seems like black magic that PASOE can distinguish between AppErrors that are THROWN out of PASOE instead of sent out via RETURN ERROR. We've always had to write this type of error handling in all our top-level classic appserver entry programs: CATCH v_AppError AS Progress.Lang.AppError: RETURN ERROR v_AppError:ReturnValue. END CATCH. If you don't have this block, then we see the following unhelpful message in our "classic" agent logs : AS -- Attempt to throw or return an error object to the client (14438). Having the block above should NOT be necessary considering the fact that a THROWN AppError("MyMessage") is virtually identical to RETURN ERRROR "MyMessage". It seems like black magic that PASOE can make a distinction between the two because, from within ABL itself, there doesn't seem to be a way to determine the difference via S.E.H. There is additional information in the KB that confirms a difference (in classic appserver) between when an AppError is raised via "THROW" or "RETURN ERROR". See: Progress KB - Error trying to pass an Error Object back to a client across the AppServer Boundary Since moving to PASOE I haven't yet reviewed whether there is still a distinction between the two ways to raise AppError. We still have quite a large amount of code running in both "Classic" and "PASOE" so it may be a while before we can remove all those repetitive CATCH-RETURN-ERROR blocks from all our appserver entry programs.
Continue reading...
Continue reading...