>Here is an example of what kind of problem you could get into using ComReturnError()
>
>

>DEFINE CLASS MyClass As Session OlePublic
>  Function SaveMyWork( oRs1, ors2 )
>
>    LOCAL loContext
>
>    This.Rs1 = oRs1
>    This.Rs2 = oRs2
>
>    *-- Create your object context here
>
>    lnResult1 = This.SaveRs( oRs1 ) && Save an ADO Recordset with some data
>
>    x = y && This causes an error and causes the program to stop executing because the error method call ComReturnError()
>
>    *-- At this point the control is given back to the client
>    *-- The SetAbort() is not called, SetComplete() is the default
>    *-- So the changes to the database will be committed even if oRs2 was not saved
>    *-- Even Worst is i stored the 2 RecordSets in This.Rs1 And This.Rs2
>    *-- and my GC Method is not called so i will for sure get a C5 at some later time when running this method again.
>
>    lnResult2 = This.SaveRs( oRs2 ) && Save an ADO Recordset with some data
>
>
>   IF lnResult1 = 0 AND lnResult2 = 0
>     *-- Call setComplete()
>   ELSE
>     *-- Call SetAbort()
>   ENDIF
>
>  ENDFUNC
>
>  **-- Some more functions here including a error function with ComReturnError()
>
>ENDDEFINE
>

>
>As you can see, ComreturnError() is the problem here, as you say we should keep an open mind, and i don't say there is no use for ComReturnError(), i just say it is very dangerous to use it without understanding it fully.
>

Although I haven't worked with COM+ on a production environment (still running NT around here), my approach is to issue SetAbort() in the error function before COMRETURNERROR(). I've never gotten a C5 because of this.

In your situation, what happens if your error-communication mechanism fails? My guess is if the component keeps running, the client doesn't know of the exception and it keeps on with further processing, which could be risky.