>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()