TRY... *again* 🙄

I have proposed a concept for TRY as trapping definitional errors and turning them into nulls, like this:

>> take []
** Error: you can't take from an empty block (stopping further code)

>> try take []
== ~null~  ; isotope

And I'll just give a reminder that as this is trapping definitional errors. So failures from deeper inside code would not be caught... only errors that are returned by contract from the function being called.

>> try compose [(1 / 0)]
** Error: division by zero (e.g. COMPOSE itself didn't raise the error)

I'll remind everyone that it's a very slippery slope to trap "deep errors", and this is why the deep error trapping concept is hidden away as sys.util.rescue)

Why Return NULL From TRY (vs. void) ?

The decision to return null is to make the result falsey so it can be acted on:

while [item: try take block] [
    ...
]

all [
    try take block  ; if this fails we don't want to keep going
    ...
]

In the vernacular I use, I call NULL "soft failure". So TRY "converts a definitional failure into soft failure", passing through all other results as-is.

Comparison with similar word MAYBE

The MAYBE operation was defined as something that converts nulls to voids, and passes through everything else. If you didn't know that, it's easy to see not intuiting what the difference between try take block and maybe take block would be.

You can get some odd-looking combinations with this, e.g.

 >> block1: [a b c]
 >> block2: []

 >> append block1 maybe try take block2
 == [a b c]

Which makes one wonder if MAYBE could be used to trap definitional errors as well as nulls and turn them into voids, so you could just write append block1 maybe take block2.

So it raises the question: are there null-returning operations that also return definitional errors, where one would want to suppress the null but not the error? There's not enough experience for me to say yet.

Usage in PARSE as opposed to OPT?

I've wondered if TRY and MAYBE could have parallel meanings in PARSE, where you use TRY to continue but get NULL and MAYBE to skip things:

>> parse "aaa" [some "a" maybe some "b"]
== "a"

>> parse "aaa" [some "a" var: try some "b"]
; first in pack of length 1
== ~null~  ; isotope

>> var
== ~null~  ; isotope

Seeing the two operations as being very similar--only one voids while the other one nulls--feels interesting. I just hadn't thought of MAYBE as a definitional-error-suppressor before.

1 Like