Re: [dcom 1.2] Implement dispatch variant marshalling

[Mike Hearn]

On Thu, 2003-09-04 at 20:53, Dimitrie O. Paun wrote:
> I'd prefer we don't have there -- they really clutter the code,
> provide a bad example to follow, and provide little, if any,
> benefit. What you can do is put some strategic TRACEs that would
> help someone who knows the code to identify the problem.
> But I wouldn't worry about memory allocation failures...

Another possibility is to have a wine convenience macro, similar to the
glib g_return_if_fail() macro, that works for instance:

wine_return_if_fail_hr(CoDoSomethingCOMRelated())

which expands to
{
   HRESULT hr = CoDoSomethingCOMRelated()
   if (hr != S_OK) { ERR("CoDoSomethingCOMRelated() failed, hr=%ld\n",
hr); return hr;
}

or whatever..... could be convenient, but perhaps too much magic. I'll
drop the ERRs then.

thanks -mike

[dcom 1.2] Implement dispatch variant marshalling

[Dimitrie O. Paun]

On 4 Sep 2003, Mike Hearn wrote:
> Another possibility is to have a wine convenience macro, similar to the
> glib g_return_if_fail() macro, that works for instance:
>
> wine_return_if_fail_hr(CoDoSomethingCOMRelated())
>
> which expands to
> {
>    HRESULT hr = CoDoSomethingCOMRelated()
>    if (hr != S_OK) { ERR("CoDoSomethingCOMRelated() failed, hr=%ld\n",
> hr); return hr;
> }

I still find this ugly, but this is maybe just me. For someone
looking at the code, it's cryptic. This is cleaner I find:

HRESULT hr = CoDoSomethingCOMRelated();
   if (hr != S_OK) return hr;

And besides, all those errors will bloat the code to such an
extent that we'll be forced to disable ALL tracing, even the
good, hand-written one. The better solution is to make sure
we have a decent way of failing in a function which is already
the case in 99% of cases. No need to generalize and make it
easier to do the wrong thing for the sake of that tiny portion
of code that needs fixing anyway.