D
dbeavon
Guest
Thanks for the tip about -debugalert. That will save me tons of time when working with our PASOE (both in dev and production). I wish I had known about it sooner. I did already know about -errorstack, but whenever I needed stack information it was unavailable and I was having to do programming to gather it after the fact. In other words, my work involved some retroactive & manual programming effort to extract the stack information. This is challenging if errors are only occurring in production. Also it was a catch-22 because without having the stack information in the first place, I don't know where to put my manual code that extracts stack information. Using -debugalert with -errorstack is going to be a life-saver, provided it's not too noisy. At first glance, it doesn't print anything to the agent log for run-of-the-mill application errors (ie. when returning regular errors via "RETURN ERROR"). That is a good thing because it means that the logs will only show unexpected/unhandled errors that a programmer hasn't accounted for. Here are the details about -debugalert if anyone is interested in using them for PASOE: OpenEdge 11.7 Documentation ...If the error was generated by throwing an error object from the ABL code and the Error Stack (-errorstack) startup parameter is used, or the ERROR-STACK-TRACE attribute on the SESSION system handle is set to true, then the stack trace also includes the contents of the CallStack property for the unhandled error. By comparison .Net, has a ToString() method which will show both the message and the stack trace by default (unless people override it and do something unfortunate that obscures that infromation). I wish ABL had a well-defined "ToString()" operation that would just puke out everything you need to know about an error and its source. As things work today, we need to do quite a lot of custom programming to get the same level of information that .Net gives in ToString(). To make things even more interesting, some ABL error types (like Progress.Lang.AppError) put the error in weird places (ReturnValue) instead of the standard places defined by the generic interface, Progress.Lang.Error. I would always expect meaningful information from the Progress.Lang.Error (via GetMessage/NumMessages) but sometimes these return nothing at all.
Continue reading...
Continue reading...