David,

It's not that simple. For instance, one of my functions, OpenTble, is used everythere in lots of places, I can not change it now. I like the idea, proposed by Doug...

>Nadya,
>
>Personally I don't like mixing 2.X style error handling (using temp ON ERROR handlers) and O-O Error() methods.
>
>I think you can convert your UDFs to methods and let them trap/handle their own errors. This code sample shows one way.
>
>

activate window "debug output"
>
>oX = createobject( "errorx" )
>oX.Method3() && errorx.error() catches it
>oX.Method1() && errory.error() catches it
>
>oY = createobject( "errory" )
>oY.Method2() && errory.error() catches it
>return
>
>
>define class errorx as custom
>
>function Error( nError, cMethod, nLine )
>debugout "errorx " + program() + str( nError )
>endfunc
>
>function Method1
>
>oY = createobject( "errory" )
>oY.Method2()
>endfunc
>
>function Method3
>error 3
>endfunc
>
>enddefine
>
>define class errory as custom
>
>function Error( nError, cMethod, nLine )
>debugout "errory " + program() + str( nError )
>endfunc
>
>function Method2
>error 1
>endfunc
>enddefine

>
>>You're right, but consider this situation: we have an application, called XFormDBF. This application has its own Error Handler. This application allows to use UDFs. One of my UDFs called OpenTble and it uses ON ERROR mechanism to check, if table could be opened. Now, this is just ignored and I see an Error from this application instead of trapping this problem by myself.