I don't put things into CPAN, but I prefer the following:
Never let a module kill the caller. Instead, return undef to indicate error, and, if it seems like it might be needed, provide another method that returns a descriptive error string. This adds to the bulk of the code, but I think it's worth it. I could be wrong.
Offload input taint checking to the calling application; within the module's methods, sanity check only. Some methods will be more robust if they do slightly more extensive testing of input data; a flexible solution is to provide testing methods outside of your setter/getter methods. This allows the user to work it: "If the input is okay, then set it in the module." Later, if you just can't stand the risk that some user is going to hose the thing with unchecked data, you can add the call to the testing method to the setting method.
I prefer combined setter/getter methods if both actions are simple. Otherwise, I prefer set_foo() and get_foo()
Regarding constructor vs. "lots of methods", I prefer to let users of my modules work in whatever way suits them best, so I generally try to support sensible defaults, overridden by any arguments to the constructor, and setter methods accessible to the user. The defaults and overrides actually call the setter methods to ensure consistency and stick more closely to the OOP.
I try to avoid forcing my will on users... TMTOWTDI and my way is usually just plain dumb.