Alexandre Julliard schrieb: > Peter Beutner <[EMAIL PROTECTED]> 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.
