>>? on("error")
>>
>>will give you the current error handler setting. You may even save it into a variable,
>
>and throughout the 'run form' exercise, it returns a null string, showing that I've successfully switched error handling off
>
>nevertheless, instead of crashing on the offending line (I can step through the guilty line and watch this happen), despite having defused the error handler, the code leaps to the error method for the form where I've inserted a nodefault in the attempt to stall it. It then protests 'no parameter statement found' and crashes in the normal way - i.e. at the offending line! Trouble is the offending line is now the first line of the error method and not the code line that caused the jump in the first place.

Check the "error event" in help - it says it has
PROCEDURE Object.Error
LPARAMETERS [nIndex,] nError, cMethod, nLine

So, no matter what you write in it, it gets passed three or four parameters. The optional parameter is received for a member of a control array (like a button in a group). You better include these parameters and simply suspend. Maybe the best thing to do is to leave the error method completely empty, you should get the default behavior of the elder class. Though, if you've built your form on FFC, you will get the error method of the FFC _Form class; in that case, you may try

LPARAMETERS nError, cMethod, nLine
form::error(nError, cMethod, nLine)
nodefault

in your form's error event code. This should give you the behavior of the base class.