D
dbeavon
Guest
Crickets. 
If I use catchStop -1, and catch it (Progress.Lang.LockConflict) then my work is fully accomplished. I am fully in control of this type of ABL error condition, and my own code will fully handle both of the possible outcomes - the outcome where my data was available and the outcome where my data was not available. What is the purpose of the logging in that case? To take a step back , what is the intended purpose of the appserver logging in general? From my perspective we should only be using the logging (after-the-fact) to discover where errors in ABL are being "swallowed" / "suppressed" / "ignored" by the ABL runtime (as a result of the default behavior of error conditions in certain ABL looping constructs). In a certain sense the DO/CATCH(LockConflict) can be regarded as "syntactic sugar". A similar thing could be easily be accomplished with manual programming. For example, we could also write our own loop of ABL code which, for ten seconds, tries to perform a EXCLUSIVE-LOCK NO-WAIT and, after the timeout has expired, throws a custom "AppError" saying that there was a conflict. In that scenario we would also be able to fully handle both of the possible outcomes. The difference is that, in the case of the "manual" approach, it would NOT result in any scary messages in the appserver logs. There would be no REASON for messages, since all outcomes are accounted for. The messages would only serve to raise unnecessary alarms from a human operator. Perhaps the first thing Progress needs to do is allow us a mechanism for first-chance error-handling. It would be nice if we could attach a custom handler that is executed when errors are first raised, and perform a custom action (like spit messages via "LOG-MANAGER"). Then it would be totally *our* choice to print certain types of errors and not others. In theory, a first-chance LockConflict is about as interesting as any other type of error you can think of (whether runtime errors or custom errors). Assuming we were given a mechanism to capture first-chance errors, the current noisy STOP conditions could then be eliminated from the appservers logs by default. Right? I guess I still have some confusion about the noisy STOP's. The confusion may originate in not understanding the purpose of appserver logging in general. Is it the intention of Progress that there is a human who is monitoring these logs moment-by-moment and correcting problems after-the-fact? That type of approach should be unnecessary and should be discouraged. The ABL code should be made more capable, so that it can work in a well-defined way whether there is a lock conflict or not. There should be no need for a human to be monitoring a log file and doing work that could otherwise be done by software.
Continue reading...
If I use catchStop -1, and catch it (Progress.Lang.LockConflict) then my work is fully accomplished. I am fully in control of this type of ABL error condition, and my own code will fully handle both of the possible outcomes - the outcome where my data was available and the outcome where my data was not available. What is the purpose of the logging in that case? To take a step back , what is the intended purpose of the appserver logging in general? From my perspective we should only be using the logging (after-the-fact) to discover where errors in ABL are being "swallowed" / "suppressed" / "ignored" by the ABL runtime (as a result of the default behavior of error conditions in certain ABL looping constructs). In a certain sense the DO/CATCH(LockConflict) can be regarded as "syntactic sugar". A similar thing could be easily be accomplished with manual programming. For example, we could also write our own loop of ABL code which, for ten seconds, tries to perform a EXCLUSIVE-LOCK NO-WAIT and, after the timeout has expired, throws a custom "AppError" saying that there was a conflict. In that scenario we would also be able to fully handle both of the possible outcomes. The difference is that, in the case of the "manual" approach, it would NOT result in any scary messages in the appserver logs. There would be no REASON for messages, since all outcomes are accounted for. The messages would only serve to raise unnecessary alarms from a human operator. Perhaps the first thing Progress needs to do is allow us a mechanism for first-chance error-handling. It would be nice if we could attach a custom handler that is executed when errors are first raised, and perform a custom action (like spit messages via "LOG-MANAGER"). Then it would be totally *our* choice to print certain types of errors and not others. In theory, a first-chance LockConflict is about as interesting as any other type of error you can think of (whether runtime errors or custom errors). Assuming we were given a mechanism to capture first-chance errors, the current noisy STOP conditions could then be eliminated from the appservers logs by default. Right? I guess I still have some confusion about the noisy STOP's. The confusion may originate in not understanding the purpose of appserver logging in general. Is it the intention of Progress that there is a human who is monitoring these logs moment-by-moment and correcting problems after-the-fact? That type of approach should be unnecessary and should be discouraged. The ABL code should be made more capable, so that it can work in a well-defined way whether there is a lock conflict or not. There should be no need for a human to be monitoring a log file and doing work that could otherwise be done by software.Continue reading...