Again, How can you go back to the method where the error occured and cleanup any object references created with LOCAL before calling ComReturnError(), I do not think it is possible so you will be stuck with dandling object references because you cant do proper cleanup .

>IMO, the best approach is to have a garbage collection method. Call it anytime you need to cleanup. Then call COMRETURNERROR(). The problems you cited are NOT due to COMRETURNERROR(), they are due to not doing proper cleanup.
>
>
>>>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.
>>
>>Yes, it would be nice if things were simple enought to call SetAbort() in The error method, but they are not. Some errors are "Normal" and the error method should trap them and ignore them, then continue executing the rest of the code, not systematically call SetAbort on error()
>>
>>Another problem with calling SetAbort() On the error() And then returning to the client with ComReturnError() is that you cant cleanup the faulty method. So if you had object created in the method you cannot go back and set them to null to decrease The ObjRef() count of the object. So will will get stuck with a dandling object reference in memory and you will get C5 at some point,
>>
>>
>>>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.
>>
>>The example i wrote is only to demontrate the problem with ComReturnError() The Error method sould in fact be a lot more developped than the example. It was just to show an other alternative to ComReturnError()