D
dbeavon
Guest
The confusing thing is that, when we first encountered it, AppError appeared to be the new "S.E.H.-equivalent" for "RETURN ERROR". I suspect most developers assumed they would interchangeable. In fact, AppError even has the ReturnValue property, presumably to imitate "RETURN ERROR" as closely as possible. ... And within ABL itself they seem to be interchangable. As you pointed out, you don't provide any possible way for a CATCH block to distinguish whether an error was raised via THROW'ing AppError or via RETURN ERROR. ... But despite all the similarity between the two, when it comes to the agent log one makes "noise" as the error is being transmitted to the .Net openclient and one does not. >> normally, if you throw an error object, you'd expect the whole object (or at least all of the relevant information in it, notably the error message) to be sent back to the client, and this is not happening. I suspect most developers to put the "relevant information" in the ReturnValue of the AppError class (via the AppError constructor which takes a single character string). For most practical purposes, the whole object *IS* being sent back to the client. (or at least it is no less information than we get with RETURN ERROR). Perhaps there were too many goals bundled up into the original design of the AppError class, and some of them actually conflict with the need for an S.E.H. equivalent of "RETURN ERROR".
Continue reading...
Continue reading...