1. Should my module's methods croak, or return error codes when they fail?

I generally feel that it is unhelpful for an object to take down an application because it's unhappy about its own state.

Why? If you view objects and being bits of data able to be acted upon, the absence or presence of that data is not necessarily an event worth 'dieing' over. Particularly in the case of objects (which are liable to be imported and used by others) you should leave the choice of what to do up to the application developer.

This is what's beautiful about Java's try{} catch{} syntax -- errors can percolate up to whatever level you care to let them, so errors can be trapped at any point of execution or simply cause the application to fail depending on the choices made by the developer.

If you feel uncomfortable doing this, then a good backup plan is to have a flag available to the developer -- say, isErrorFatal() -- that allows the developer to choose whether or not a failure within the object is fatal to the application.

This is, of course, a generalization, but I'd go with returning undefined and setting an error flag for all but the most serious cases.

2.Should I use generic methods that can both get and set, or is a single one each, e.g. $o->debug or $o->set_debug(1); print $o->get_debug?

Here I have to respectfully disagree with vladb. Beyond the reasons outline by Ovid (what if your method doesn't actually *accept* input), are issues with flexibility and maintainability.

What if I want to create a wrapper object that only exposes the getter features of the RSS class? This contract is a lot more clear when there are separate methods to perform each action.

From a maintainability standpoint I also think that the clearer your method names the less likely you are to have problems down the line when you want to re-write the class or update a specific feature. Compare looking for what needs to change when you have a method called getDatabaseConnection() versus one just called connection().

More clarity is almost always better.