The only error which can be generated inside the editor during normal
operation (apart from loading and saving documents, opening channels,
illegal special function calls, and unknown escape sequences) is
.VCURS which is returned if an invalid cursor position is
given in the cursor positioning escape sequence.
However, since the editor is communicating with a video page and a keyboard channel, it can get errors from these channels. Generally an error from one of these channels means that the channel is misbehaving in some way. For example if someone has redirected the editor's video channel to a different device, or even closed it then the editor will get errors from its video channel.
If an error does come from one of these channels then the editor returns
either .EKEY or .EVID error code to the
applications program. It also remembers that this error occurred and
whenever it is next called, with any EXOS call, it checks the channel (by
writing a null to the video or reading status from the keyboard) to see
if it is basically working. If it is working then it clears the error
flag and carries on normally. If it is not working then it returns the
appropriate error code (.EKEY or .EVID) to the
user without carrying out the function call.
This procedure ensures that the applications program can tell when the editor is having trouble with its secondary channels and attempt to put things right. This is how BASIC manages to recover if the editor's video channel is closed. BASIC discovers this and reopens it again.
Another feature is that if a NULL (ASCII code 0) is written to the editor, instead of just being ignored, it is written directly to the video page, which will ignore it. This provides a wat to 'poke' the editor to check if its video channel is still there, without having any effect on the editor's data.