Re: Thoughts On Object-Oriented Module Design. Input Sought.

My thoughts...

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

Error codes. Over the years, I've run into more libraries than I care to think about (mostly C, not perl) which die and take my app down with them when they think something went wrong. I don't care if your code absolutely, positively has to have a certain database available in order to function - return an error code so that the caller can then decide to use an alternate implementation, create the database you need and try again, or just die if nothing else works. Unless you know that there is no way the caller could possibly cure your 'fatal' condition, just tell it. Don't croak without warning.

Side question: I'm currently debating with myself over when it's appropriate for a method to report an error to STDERR on its own instead of just passing back an error code to the caller and letting them decide whether to report it or not. Thoughts?

How much internal error checking is sensible?

Sanity checking is always good. Don't make assumptions in your code - if it's possible for you to be passed bad data, make a reasonable effort to ensure that you didn't.

Should I use generic methods that can both get and set, or is a single one each

I go with generics. In my experience, that seems to be the more common perl idiom.

What works best, lots of methods to set things, or via the constructor in one go?

Both!

Comment on Re: Thoughts On Object-Oriented Module Design. Input Sought. Download Code

Replies are listed 'Best First'.
Re: Re: Thoughts On Object-Oriented Module Design. Input Sought. by gloryhack (Deacon) on May 07, 2002 at 16:50 UTC
`Side question: I'm currently debating with myself over when it's appropriate for a method to report an error to STDERR on its own instead of just passing back an error code to the caller and letting them decide whether to report it or not. Thoughts?` I believe that most of the time, methods within a module should not screw around with their environment. However, if reporting to STDERR is seen as convenient, I prefer a module that will provide a switch to turn STDERR reporting on or off, defaulting to the off state. When I encounter a module that insists upon spewing at STDERR, I add to my own code a method for redirecting STDERR to /dev/null, and turn it on at the same point at which I comment-out the uses of the strict and diagnostics pragmas. I think that by providing the switch in your modules, you allow your user to operate more completely within TMTOWTDI space.	[reply]

Replies are listed 'Best First'.

Re: Re: Thoughts On Object-Oriented Module Design. Input Sought.
by gloryhack (Deacon) on May 07, 2002 at 16:50 UTC

Side question: I'm currently debating with myself over when it's appropriate for a method to report an error to STDERR on its own instead of just passing back an error code to the caller and letting them decide whether to report it or not. Thoughts?

I believe that most of the time, methods within a module should not screw around with their environment. However, if reporting to STDERR is seen as convenient, I prefer a module that will provide a switch to turn STDERR reporting on or off, defaulting to the off state.

When I encounter a module that insists upon spewing at STDERR, I add to my own code a method for redirecting STDERR to /dev/null, and turn it on at the same point at which I comment-out the uses of the strict and diagnostics pragmas.

I think that by providing the switch in your modules, you allow your user to operate more completely within TMTOWTDI space.

[reply]