Have you checked to see if there is an ERROR() event active in the context in which the particular code is run? If you've got an ERROR event active, it will get control rather than the ON ERROR (basically in this case the ON ERROR will *not* trigger since the ERROR() event code will be triggered instead).

#DEFINE _NL_   CHR(13)+CHR(10)

* Let's first call PSub2 directly
DO PSub2

* Now call it indirectly within context where ERROR() event is present.
oTst = CREATEOBJECT("T_ErrTrap")
oTst.DoCmd("DO PSub2")
IF oTst.bOkFlg THEN
    ? "OK"
ELSE
    ? oTst.cErrMsg
ENDIF
RELEASE oTst

RETURN .T.

PROCEDURE PSub1
    LOCAL cErrTrap, nErrNum

    cErrTrap = ON("ERROR")
    ON ERROR nErrNum = ERROR()
    nErrNum = 0
    = "A"+1
    ON ERROR &cErrTrap.
    ? "nErrNum = ", nErrNum
ENDPROC

PROCEDURE PSub2
    DO PSub1
ENDPROC

DEFINE CLASS T_ErrTrap AS CUSTOM
    bOKFlg   = .T.           && Indicates if everything ran OK or not
    cErrMsg  = ""            && Error message indicating nature of failure

    PROCEDURE ERROR
        LPARAMETERS nError, cMethod, nLine

        THIS.bOkFlg = .F.
        THIS.cErrMsg = "Error "+TRANSFORM(m.nError) ;
            +":"+MESSAGE()+_NL_ ;
            +"Error on line "+TRANSFORM(m.nLine)+" in "+m.cMethod+_NL_ ;
            +"Command: "+MESSAGE(1)
        RETURN
    ENDPROC

    PROCEDURE DoCmd( cCmd )
        &cCmd.
    ENDPROC
ENDDEFINE  && T_ErrTrap

>In some legacy code there's a function SafeCmd() to execute some commandline and do this safely. If it fails it returns an error number. It always worked well, until recently. The command "use xxxx exclusive alias xxxx" correctly returns error 1705 (access denied) if the table is already opened by some other application. However, in another routine a similar call incorrectly returns error 0.
>
>I could repair the routine by making variable m.error PRIVATE instead of LOCAL.
>Another way was to rename m.error to e.g. m.lnError (and keep it local).
>
>My hunch is that, under (for me obscure) circumstances, the ON ERROR handling is occurring OUT OF THE LOCAL SCOPE (where it is not out of the private scope). Or that VFP internally can get confused when processing: m.Error = ERROR()
>
>Who's got a clue to what may be the problem here? I'm not so much interested in a solution (actually, we'll gonna use the array from AERROR instead), but more in the how, why and when of this quircky behavior.
>
>

FUNCTION SafeCmd
>	LPARAMETER m.Command
>
>	local m.Error, m.OnError
>*	private m.Error, m.OnError
>
>	m.OnError = ON( 'ERROR' )
>	m.Error = 0
>
>	ON ERROR m.Error = ERROR()
>	&Command
>	ON ERROR &OnError
>
>	RETURN m.Error