Just for fun, consider code which involves tentative execution. (This roughly approximates the issue I was struggling with today.)
Here, we want to fall back to plan B when we hit an error. However, we may not have convinced ourselves that plan A has been implemented correctly. (Let's say that plan B has high cost and plan A is cheap for the typical case but fails in certain rare cases.) So, for example, we might identify a suspicious line in code executed under the try block and put a stop on that line. This can be treated with the current implementation, by modifying the code (implementing the logic we need to stop only for the suspicious case). But it takes a very clear understanding of the try./catch. mechanics to understand how to proceed here. Anyways, in this context, there's a need for a catch. block, and there's a need for debugging to work on code executed in the try. block. It's valid to say that catchd. is not needed here, but only because we have another way of enabling debugging for the try. block. FYI, -- Raul On Wed, Jan 12, 2022 at 4:02 PM Henry Rich <[email protected]> wrote: > > I agree that some discussion about this would have helped before it was > implemented, or at least so the documentation could explain the reasons. > > We often put try./catch. around upper levels of an application so that > we can recover from unexpected errors in our own code. Presumably we > will then want to debug our code. > > There is another use for try/catch.: executing code where failure does > not indicate an error, but is simply one of the possible results. Maybe > we read lines from a file and execute them. If they don't execute, our > code takes some appropriate action. Failure of the try. is not a program > logic error. > > It seems to me that catchd. is the right choice for the first type, and > catch. for the second. There is never a need for both. > > If this explanation is right, it means I now understand it for the first > time. > > Agreed that the try. page should have examples. > > Agreed also that a stop is not an error and does not cause execution of > a catch?. block. > > > > hhr > > > > On 1/12/2022 1:31 PM, Raul Miller wrote: > > I can't give a good answer for question of where this detail needs to > > be documented, because I do not adequately understand why this detail > > exists. > > > > Taking a step back, for perspective: > > > > catch catches errors even if the debug flag is set. But, it currently > > does not trap a stop. Therefore, in the current implementation, a stop > > must not be an error. > > > > Proof: > > ex=: {{1+y}} > > exa=: {{try.ex y catch.3 end.}} > > 13!:0]1 > > 13!:3'ex 0' > > exa 9 > > 10 > > > > If stops were errors, then exa would have returned 3 instead of 10. > > > > catchd. catches errors only if debugging is disabled. This would mean > > that it ignores errors when debugging is enabled. I cannot imagine a > > use for this feature in the current implementation (or, really, in any > > circumstances -- by that's presumably a limitation of my current > > imagination). > > > > (catcht. catches throws. It's not clear from the documentation whether > > a throw is an error, but experimentation suggests that it is.) > > > > So it looks like try. temporarily disables suspension unless a catchd. > > block is present. > > > > Assuming that the current behavior is the intended behavior, this > > suggests that the mention of "the setting of the debug flag 13!:0" and > > this behavior belongs on the try. keyword, and not on the catch. > > keyword. Additionally, the catchd. keyword should mention that its > > presence allows suspension in the try block. > > > > --- > > > > Put different, there's two questions from my perspective: > > > > (A) what behavior should be implemented, and > > (B) how should that behavior be documented. > > > > Consider this example: > > > > ex=: {{13!:}} > > exa=: {{try.ex y catch.3 catchd.4 catcht.5 end.}} > > 13!:0]1 > > 13!:3'ex 0' > > (;$)exa 10 > > |stop: ex > > | 13!: > > |ex[0] > > 13!:5'' > > ┌┬───┐ > > ││0 0│ > > └┴───┘ > > > > Here, execution was "resumed" but none of the catch blocks were executed. > > > > I find this behavior puzzling, and I do not feel certain that the > > implementation is correct. > > > > Thanks, > > > > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
