$bvar(&nonexist,1-).text should return null string

When passing a non-existent &binvar to $bvar().text, mIRC throws an error.
I believe it should return null empty text instead, since the parameters are not invalid.

//echo -a $bvar(&nonexist,1-).text
> * Invalid parameters: $bvar

To prove that the parameters are indeed not invalid, this similar command works.

//echo -a $bvar(&nonexist,0)
> 0

Thanks for your bug report. This is intentional. Ideally, $bvar(&nonexist,0) should also return an error. That would be my preference. However, at the time this was implemented, scripters appeared to be happy with the behaviour, and now that it has been in place for so long, changing it would break existing scripts.

I perfer the current behavior of $bvar(&nonexist, 0) It reduces two checks to one

Code

if ($bvar(&nonexist, 0)) ...

if ($bvar(&nonexist) && $bvar(&nonexist, 0) > 0) ...

with $bvar(&nonexist, 1-).text or $bvar(&nonexist, 1, ...).text I wouldn't be against it returning an empty string

So how do we safely handle imaginary binvars without our scripts crashing all the time, if not with an if-condition checking that a $null string is returned?

Is this what $error /reseterror is for?

$urlget(%id).target sometimes makes up imaginary binvars for instance, so how is that correctly handled?

(Currently) to check if a bvar exists without throwing an error you use $bvar(&bvar) then if the check passes use $bvar(&bvar, 1-).text to get the text

With that said, returning $null/an-empty string is more consistent with other identifiers than throwing an error; case in point: hashtables

Code

echo -a >> $hget(nonexist, item)

hmake exists 1
echo -a >> $hget(exists, nonexist)
hfree exists

Quote

With that said, returning $null/an-empty string is more consistent with other identifiers than throwing an error; case in point: hashtables

Alas, this does vary across commands/identifiers, probably because every time I add a new feature, a different user is requesting it, and some users ask for an error to be reported in some situations, while others ask for a default value to be returned in place of an error, to make coding easier so that they do not have to check for errors.

In this case, the purpose of the error is to indicate to the scripter that they have typed a variable name incorrectly in their script. If an error wasn't reported, they may not notice it in a large script without a lot of debugging.

And we would then probably end up with the opposite bug report, ie. it should report an error.