Is it ok to type check a boolean argument?

Scott David Daniels Scott.Daniels at Acm.Org
Thu Jan 8 01:21:06 CET 2009


Adal Chiriliuc wrote:
> On Jan 7, 10:15 pm, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
>> ... I'd either keep the argument as a boolean but rename it "ascending" ...
> 
> Well, I lied a bit :-p  ....
> But what if we can't solve it as elegantly, and we need to ...
> 
> Should we typecheck in this case to ensure that if we pass a string
> for "fast_mode" we will raise an exception?

Why are you concerned only with type errors on inputs?
Even if you could do exhaustive checking of input parameters to
make sure they are the only acceptable values, what prevents your
user from providing the wrong valid value?  What made you pick on
type errors in the first place?  If it turns out that an argument
of 422 is a typo for 42, why is that less of a problem?  Just because
you are used to systems where one kind of error is always caught does
not really make you invulnerable.  You'll have no problem telling
your users that the 422 is their fault.  Why do you have such
certainty that passing in "nonsense" as a boolean is a failure
you need to deal with?

Anyhow, you can guess where my votes would go.  If the failure in
results will come sufficiently far removed from the bad entry, I
sometimes resort to input validation.  Often those cases are for
setting attributes used much later in an interactive environment.
Maybe you can layer your checking in: have a subclass that wraps
calls with lots of checking, and see if the subclass or the base
is used more.

One place I have needed validation is in setting callbacks, since
the callback typically gets called asynchronously, and I have
trouble discovering why those things blew up.  If I can, I manage
to try the callback once first, hoping for an early explosion.

--Scott David Daniels
Scott.Daniels at Acm.Org



More information about the Python-list mailing list