Could there be a foreign that generates an "error pyx"?
A functional/debugless error handing/processing model.
f error = error passed through.
raising error function y = above error state ; < f ; y ; x (or last 2-3 boxes
in ar format suitable for `:6. boxed to make 1 item for consistency with monad
dyad function shapes)
A way to unify pyx and sequential code for "later consumption" with simple
error management/awareness is (a cruder version of this non pyx)
t =: t.''
P =: 1 : ('(u y) (;<) (u ar) ` (y ar) '; ':'; '(x u y) (;<) (x ar) ` (u ar) `
(y ar)')
ERROR =: 0 1 0 $ _
isErr =: ((< ERROR) -: {.@{.@:])
E =: (`])(@.isErr)
mkerr =: 1 : 'u :: ((ERROR ; 13!:11 ; 13!:12)@:(''''"_))'
2 + E 'a' < mkerr 1 2 3
┌┬─┬──────────────────────────────────────────┐
││3│|domain error | 2+E'a' <mkerr3 1 2 3 │
└┴─┴──────────────────────────────────────────┘
With boxes/pyxes having metadata returning an error code, being able to use
that "internal J metadata" would be preferable to this "roll my own functional
error handling".
Note that some info (error position/line) in error handling in a thread gets
disabled:
> 'a' < mkerr t. '' 1 2 3
┌┬─┬──────────────┐
││3│|domain error │
└┴─┴──────────────┘
I mentioned, user building the "calling code" along side the pyx. This is for
the ultra rare condition where a retry on the code might be fruitful. An
alternative would be 41&T. pyx(es) returning the "full" 13!:12 info instead of
this shorter one. 13!:12 linear copy of (error) text includes indent hints of
where in the code caused the error.
Async code is going to manage a list of pyxes for further processing, often
ignoring (leaving in queue or removing to add to an error reporting queue)
those that returned errors. The code that caused the errors is useful info,
because it probably has a bug. A foreign that adds the same metadata to boxes
such that 4&T. can filter for "general functional errors (return values)" is
needed/good if only because sequential boxes can be added to pyxes "further
processing lists"
On Monday, April 11, 2022, 09:01:29 a.m. EDT, Henry Rich <[email protected]>
wrote:
Correct that 'boxes' not 'pyxes' is what 4 T. operates on. (A pyx is
also a box).
Incorrect that a pyx turns into a box when it completes. It's still a
pyx, as you will see if you open it and it contains error - the error is
signaled to you on the opening.
Henry Rich
On 4/10/2022 9:49 PM, 'Pascal Jasmin' via Beta wrote:
> The argument is a box or array of boxes as documented. _1001 is return value
> if not a pyx, and _1000 (completed pyx) is I think not a pyx anymore.
>
>
>
>
>
> On Sunday, April 10, 2022, 09:33:37 p.m. EDT, Elijah Stone
> <[email protected]> wrote:
>
>
>
>
>
> On Sun, 10 Apr 2022, Joe Bogner wrote:
>
>> It would be more clear I think if it said "A pyx or array of pyxes" -
>> https://code.jsoftware.com/wiki/Vocabulary/tcapdot#dyadic. I'm not
>> comfortable updating the wiki with this recommendation unless others
>> agree.
> I think that change is sensible. I might even shorten to simply 'array of
>
> pyxes'.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
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
