>>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,
>

I do not follow your comment on what constitutes a normal error. I guess it depends on the type of the application and to what extent you expect and are willing to live with exceptions. In the MTS-based apps I've built the error has to be notified immediately to the client so it reacts accordingly.

And if you already took the precaution of declaring all variables LOCAL (as suggested in one of your posts in this thread) what cleanup is there to do? Unless you need to save state there should be no need to go back and release LOCAL variables. Further, if we are talking MTS/COM+ components the call to SetAbort() releases the object and any resources it was using at the time. Of course you cannot foresee things like C5's where the results are unpredictable.

I guess I agree on most of the points except the one on not using COMRETURNERROR(). In my experience it has been a reliable way of returning error information from an MTS call gone awry.

Just my .02

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