Currently if you try something bad in EVALUATE, it throws an error:
>> evaluate [unspaced null] ** Script Error: unspaced requires line argument to not be null
As EVALUATE is a relatively low-level function, it would seem more likely one would want to handle the error on the same basis as other possible return values:
; assuming EVALUATE returns [product position] >> evaluate [unspaced null foo bar] == [**unspaced-null [foo bar]]
In this case, the bomb isn't particularly informative and seems reasonable to say 'user beware—assume errors will happen'. It's kind of difficult to work around too.
This sort of puts it in the same class as TRAP with different semantics:
trap [ok ok something bad] => [**something-bad null] trap [ok ok] => [null ok] evaluate [something bad ok ok] => [**something-bad [ok ok]] evaluate [ok ok] => [ok [ok]]
I guess the wrinkle here is how do you determine where
something bad ends and
ok ok resumes? That may or may not be obvious.