> > > > I have a class with an init method that is getting bloated with >> error-checking guard clauses. >> > > Thats very strange. We don't usually have to check types in Python, > it is a dynamic language and we can use duck-typing and exceptions > so we don't usually care too much about types. Are you sure you > really need all that type checking code?
Hmm...for my scenario I thought I needed to bend that rule, but if I explain the use case perhaps you can offer alternatives. Much of my error-checking aims to ensure that a class is "fed" the correct type of data. For instance, I included a type check for a string to make sure that a future programmer (or myself) wouldn't try to pass in a list of lines after a text has been split. Other code internal to the Question class depends on the fact that the incoming data arrives in the form of a single string. If the wrong data type is fed, then I have a custom exception that gets raised to specify the problem. I guess the program would just crash with a TypeError if a list of lines was fed rather than a string, so even without the guard clause the processing would not take place. Is it better in such cases to just let the program die a natural death, without cluttering things up with such anticipatory guard clauses? I have to admit, it certainly does clutter up the code and seems to be leading to a lot of additional unit testing overhead. Is there a better way to approach these issues?
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
