John-Mark Gurney wrote: > Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200: > > What is wrong with returning an IO error? > > > > I always hated panics because of filesystem corruptions. > > An alternative would be to just bring that filesystem down. > > Its easy to panic a whole system with a bogus filesystem on a removeable > > media. > > If you're file system is so hosed that it does this, then panicing > is the only safe thing to do. You don't know what continued operation > will do to the filesytem, and you might end up losing more data. > > It is not unresonable to put parameter restrictions on function calls. > It is not much different from enforcing that a pointer is not NULL when > being passed as an argument.
There are several reasonable times to do parameter checking: o When your underlying device does not support all the available parameter combinations of your interface, but some other device does (i.e. your device is a subset, and you want to support it anyway, even if it has to offer degraded functionality). o When non-enforcement results in a regression for a third party driver or software package. o When the interface is intended to be a non-fragile one between your code and a third party's code, and you don't trust the third party's code not to cause an error in your code (you could always somewhat work around this one by claiming that the third party software caused an unrecoverable fault in passive voice, the way Microsoft does when VMM32.VXD gives out a pointer and later loses its cookies over seeing it given back). That said, I think that doing parameter checking in functions for interfaces that are non-sparsely implemented underneath is a bad idea, and only damages performance. I have seen this taken to the extreme at a former employer, with disasterous results on performance. -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"