S
slacroixak
Guest
Just to insist a bit on that: my top goal is not to avoid such an error message to be displayed, but to be able to catch the detail of that message after the end user clicks on OK, so we can log and gather those errors and be aware of what is happening on the fields. For now, we are blind in this respect, and the only option we have is to ask our customers to send us screenshots. Of course the new mechanism that you mention would be much better, and we would then display some part of the message with our own message. Now I guess that in order to not break compatibility, we would need a new Exception Super Type a bit like the Throwable type in Java which the Exception type inherits from. I mean, in the Java world, when a Sql Connection is dropped, you cannot catch it with a try catch Exception myException, but I believe I could with a try catch Throwable myThrowable. So, in order to catch an error 293, I would suggest that the block that does the RUN job would not be able to catch the error with the current top generic Progress.Lang.Error interface, but with a new super type above it called Progress.Lang.Throwable or Progress.Lang.StopError: DO ON ERROR UNDO, THROW: RUN nonExisting.p. [...] CATCH myError Progress.Lang.Error: /* will not catch err 293 / END. CATCH myStopError Progress.Lang.StopError: /* this would catch err 293 */ END. END
Continue reading...
Continue reading...