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
