D
David Abdala
Guest
Hi all, I must disagree with the implementation proposal, due to the fact that it changes CATCH semantics. What I see is two different things when it comes to the STOP: - The STOP condition - The ERROR that raised the STOP condition The STOP condition, for me, *is not an ERROR*, it may be the result of an ERROR. I think you already realized it by proposing two different objects to handle STOP conditions. Making actual CATCH blocks catch STOP changes CATCH semantics, and I don't like it. I think you should handle the ERROR that raises the STOP condition (if exists) with current ERROR semantics, that is, with an CATCHable object, that will get caught by existing CATCH blocks, catching base error objects. BUT the STOP condition should behave as it does, bubbling up, until finding a specific catch block for the STOP, once in a 'secure level'. The general behavior I want is: - An STOP condition is raised - If there is an error associated to the STOP condition, then it will be caught by the corresponding CATCH block, honoring every FINALLY along the way - The STOP will keep bubbling up until a CATCH STOP is found, honoring every finally block along the way. Alternative paths: - If no CATCH STOP is found, current STOP behavior happens, honoring FINALLY blocks - If no CATCH for the STOP ERROR is found, current *uncatch* behavior happens, honoring FINALLY blocks So, in the end, you will have to explicitly code for STOP conditions, avoiding getting bitten by the semantic change in CATCH. Take into account I'm not really versed in STOP condition handling, and that my main goal is to avoid semantic changes.
Continue reading...
Continue reading...