Alexandre Julliard schrieb:
Peter Beutner p.beutner@gmx.net writes:
Or look at it from the view of a user developing a winelib application. I'm sure he will very much appreciate it when wine does a better parameter checking than MS and returns an error instead of a crash backtrace ;) Imo a library is supposed to validate given parameters as much as possible and rather return an error to the caller than to crash.
It's just the opposite actually. A good library (which the MS ones certainly aren't...) should crash on bad pointers, so that bugs can be found and fixed. Hiding bugs and trying to stumble along is the MS way, this is what leads to idiocy like having an exception handler in lstrlen(). So if in this case Windows doesn't have a check we certainly don't want one either.
I fail to see in how far returning an error is hiding a bug. Imho if the library detects an error[*] it should pass the information to the application and let the application handle it. The library doesn't know if the application maybe can cope with it. Just ultimately crash is a bad idea imo.
Just take the example you have written something in Office and the given behaviour(passing a NULL pointer) happens when you click on the print button. If it crashes your work is lost, if it returns an error( and the app handles it in a sane way ) you just won't be able to print it, but may save it and print it somehow else. In that case my main concern is certainly not that a crash helps me to find a bug, but to don't loose my data ;)
[*] Obviously you can't check against every possible failure. And it certainly may be a bit too much to check against bad pointers in general, but a NULL pointer check is cheap, easy and certainly doable.