undefined type

[nnnik]

With the recent suggestion of null and other types I thought I would share my idea for a new built-in type - the undefined type.

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

Rules for resolving expressions encountering undefined on the same line:

• 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

That gives us the problem that we now have corruped values that we cannot repair in any way - even if we handle the undefined.
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.

[Helgef]

Hello nnnik, thanks for sharing your ideas.

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.

This seems very appropriate .

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

The question here is, what caused the undefined, I guess you mean arr.undefined() either returns undefined or the method undefined() doesn't exist. In any case, eg, method() might return undefined, so it is not necessarily clear what should be handled. Well, as pointed out by lexikos recently, the exception system is incomplete so this is more of a general problem, not necessarily a problem with your suggestion.

The repair idea is interesting, it could be useful. If there was a complete documentation, it would be easier to make more comments.

Cheers.

[nnnik]

Thank you for your comment

In either case my point is that an undefined value was returned.
If undefined error types could accept an exception:

Code: Select all

arr.undefined() {
	return undefined(exception("Did not start the library",-1))
}

Edit:
It is not really a suggestion to extend the exception system but rather makes it possible for us to use either the error checking way or the try-catch way.
This eliminates the need to decide between code structures - as lexikos pointed out in another post of his.

Essentially:

Code: Select all

if (errorCause()) is undefined
	handleErrorCause()

Code: Select all

Try
	errorCause()
Catch e
	handleErrorCause()

Becomes the same with the undefined type.