> Patrik Stridvall <psÉleissner.se> writes:
>
> > NULL values are not garbage IHMO, there are legitime uses
> for depending
> > on NULL values returning failure because
> > 1. Checking for NULL is a waste of time since the API
> already does it.
> > 2. An explict check "pollutes" the code and is potentially
> less readable.
>
> This is unfortunately the attitude that Microsoft is promoting in
> Win95; but it is _wrong_. If a function doesn't expect a NULL pointer
> and gets one, this is an application bug; by hiding them Microsoft
> only makes debugging applications harder.
Note that checking explictly for NULL or checking the return value
are complete identicals operation from a purely semantical point of view
What difference it their between:
if(arg1==NULL || arg2==NULL || !Foo(arg1, arg2)) {
/* Handle error */
}
or
if(!Foo(arg1, arg2)) {
/* Handle error */
}
So you are probably want it to crash (throw an "SEH") instead.
Great now we need to do
__try {
bResult = Foo(arg1, arg2);
} __except(/* something */) {
bResult = FALSE;
}
if(!bResult) {
/* Handle error */
}
Don't you think.
if(!Foo(arg1, arg2)) {
/* Handle error */
}
is much nicer.
Because you are not really suggested that we let the application crash?
Sure it helps for the programmer that has a debugger,
but the user that run the application won't be very happy
when he loses his not recently saved document.
Throwing exception is a double edged sword, it is very powerful
but if you don't catch it in _every_ function you are almost
guaranteed that the internal state of the application will be badly
damaged. Functions returning FALSE is increases the chance of
recovery quite a lot even for carelessly programmed applications.
In short crashes/exceptions might be useful for programmers,
for fixing "can't happend" cases but for the user of the
application it is worse than useless.
Exceptions look very nice on paper but in real life,
it is preferably to avoid them unless in special cases.
> In our case it can either be an app bug or a Wine bug, and we can't
> know until we have looked into it. If it turns out to be an app bug,
> _then_ we have to add a NULL check; but the last thing we want to do
> is to add preventive checks everywhere, since this will hide Wine bugs
> too.
Personally I think we are much better off using some about mechism for
cathing Wine bugs. We could use my previous suggested FAIL macro,
we could use MFC style ASSERT, we could use some other mechanism.
Suggestions?
> So yes, we may want to have more checks in 1.0; but we must not start
> adding them before the rest of the code has been debugged properly.
I repeat, we can use other mechanism for catching bugs, using incorrectly
implemented functions is not the way to go IMO.
