A question arises if you write something like:
foo: func [] [
return fail 2
]
Or just:
panic third [a #b (c)]
INTEGER! and GROUP! don't have meaning in the "error dialect"... at this time. Whereas something like a TEXT! message is turned into an error:
panic "Text is automatically used to MAKE ERROR!"
A BLOCK! is also made into an object, and today it's simple:
fail ["Unexpected mode:" mold mode]
...although I have had ideas that you could label error arguments in some dialected way:
fail ["Unexpected mode:" mode: (mode)]
And that would give you an ERROR! which had a e.mode field you could read out of it.
But Back To The Question...
What if you pass an arbitrary non-ERROR! value that doesn't have specific meaning in the "failure dialect"?
Right now, you'd get a type-checking error on the call itself. So if you called either FAIL or PANIC with something like an INTEGER!, it would elevate to an invalid argument panic that would implicate the callsite.
But if you pass PANIC a FAILURE! (error antiform), then that failure itself currently elevates to a panic that doesn't get processed "normally" by the PANIC you're calling. But should it handle it "normally"?
The reason I ask is because in the API it may come up that you call a function, get a Value* API handle that's a FAILURE! back, and not know how to deal with it so you want to panic. But you might want to panic cooperatively. So return rebPanic(failure);
Hence more generally, panicking on a FAILURE! seems like a deliberate promotion which is saying "I'm purposefully panicking on this failure". It's doesn't seem to deserve the same kind of "invalid argument" treatment as panic 7.
I think that is reasonable, suggesting that PANIC should accept FAILURE! as one of its legal argument types, and it shouldn't be distinct in handling from if you passed it a non-antiform ERROR!
But is there a corresponding rule for FAIL on a FAILURE! ? e.g. should FAIL be willing to treat the argument failure as the failure it intended?
That seems more dubious, and I'm not exactly sure why.
Random Idea: FAILURE! vs. ERROR! to unify Error Trapping
It occurs to me there might be an opportunity here, to unify the "abrupt panic intercept" vs. "cooperative failure intercept" routines by returning ERROR! vs. FAILURE!.
e.g. if you write:
rescue [fail "hi"]
Then you'd get an ERROR!. But if you wrote:
rescue [asdfjkasjdfkjasdf]
You'd get a FAILURE! back.
Thinking along these lines, FAIL on a FAILURE! wouldn't just be allowed, it could be the implementation of PANIC.
That's an interesting thought, because it would collapse the number of communication paths (the "panic path" and the "failure path").
Avoid Invalid Argument Panics With Literal Arguments?
One avenue of exploration of the question of control over "invalid argument" errors occurring when you're in the process of trying to generate an error is just to take the argument to PANIC (and FAIL? literally... like in the design for CRASH?
This would mean panic 1 / 0 wouldn't even work, because PANIC would receive just 1 as its literal argument. You'd have to say something like panic (1 / 0) which passed the GROUP! to PANIC thus putting it in control to do the evaluation, so it would have the ultimate say in how to handle the situation.
(CRASH is more extreme in guaranteeing no evaluations will occur once the word CRASH is encountered, and only accepting a dialected block with no evaluations.)
Deep Thoughts, But My Original Question Was Smaller
What provoked my thinking was that there was C code inside the system which ran things like panic (arg) which noticed that arg wasn't a pointer to a UTF-8 string, and wasn't a "context pointer" to an ERROR!'s data structure, but just an ordinary value.
So it would treat this as if you had written:
panic (Error_Bad_Value(arg));
But this wasn't matching what the interpreter would do with panic arg if arg was 1. You'd get an invalid argument error on arg, not a generic bad-value error coming from that panic.
I think the right way to do this would be panic @arg (assuming @ is not taken for iterators, which is diminishingly likely since at arg is less symbol-y and these kinds of applications feel more powerful.)
Hence I think the panic (arg) calls in the system need to be changed.