It can be checked if it is of it's own type and it can be assigned to variables, though whenever it is used in any other way it will throw an error - even when evaluating it to boolean or checking it for other types.
The error has to be set by the code returning the value. When it is triggered it will throw an error pointing to it's creation point.
Code: Select all
Msgbox % get_value() ;would throw the error
get_value() {
arr := load_array()
return arr.undefined ;probably pointing here
}
parse_data(string) {
;idk something like JSON -> Object
}
load_array() {
return parse_data()
}
For convenience it might be nice not to throw an exception in the same expression that resulted in the undefined.
This would allow us to do things like:
Code: Select all
if ((value := arr.undefined().val.val.val.method()) is undefined)
;do whatever to handle this case
- all actions that would trigger undefineds error and function calls/method calls:
returns undefined - outermost assignments:
corrupts var and will make them act like the undefined (only corrupts here if their return isn't used)
So essentially only if they are the outermost expression on the line or inside
So another capability of undefined should be the ability to dismiss it's corruption:
dismiss(corrupted_value) or dismiss()
The former will dismiss the effects of the undefined value and revert the variable to its previous state.
The latter will do the same but will throw all undefineds if there is more than one.
If the undefined is released before it has been dismissed or observed (as in "is undefined") it will throw an error.
That can happen if it does not corrupt any variable and the expression ends or if the corrupted variable gets overwritten.