M
marian.edu
Guest
David, the catch block did changed the on-error semantics already, it’s hard sometimes to move forward if we keep on looking behind 
For me stop was always some sort of error, just found out there is actually a ‘stop’ statement so one can raise the stop condition from 4gl… and yes, no message is being given so that might count as one of those cases when stop occurs without an error message. Wonder if anyone actually uses that and if yes what the use case was, why not simply returning error for instance? It’s like a ‘fatal error’ that should bubble out till catch with on-stop else will just restart from the start-up program. No matter how you look at it a stop condition is a signal of an error and the fact that you need special handling out of catch block for that is confusing for anyone that has any prior experience with try/catch out of the 4gl world. Given Rob’s proposed solution if you really want to let the stop bubble out of the catch block just add a stop statement at the end of that block, chances are those that started to use try/catch already work around stop conditions so the semantic change will most probably be in-line with what they wanted in the first place but had to add unnecessarily on-stop undo, retry and check for retry in the main block. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212
Continue reading...
For me stop was always some sort of error, just found out there is actually a ‘stop’ statement so one can raise the stop condition from 4gl… and yes, no message is being given so that might count as one of those cases when stop occurs without an error message. Wonder if anyone actually uses that and if yes what the use case was, why not simply returning error for instance? It’s like a ‘fatal error’ that should bubble out till catch with on-stop else will just restart from the start-up program. No matter how you look at it a stop condition is a signal of an error and the fact that you need special handling out of catch block for that is confusing for anyone that has any prior experience with try/catch out of the 4gl world. Given Rob’s proposed solution if you really want to let the stop bubble out of the catch block just add a stop statement at the end of that block, chances are those that started to use try/catch already work around stop conditions so the semantic change will most probably be in-line with what they wanted in the first place but had to add unnecessarily on-stop undo, retry and check for retry in the main block. Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212Continue reading...