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.

In reply to Re: Re: Thoughts On Object-Oriented Module Design. Input Sought. by jreades
in thread Thoughts On Object-Oriented Module Design. Input Sought. by ajt

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.