Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Turning a script into a module

by eyepopslikeamosquito (Archbishop)
on Jul 17, 2003 at 05:02 UTC ( [id://275110]=perlquestion: print w/replies, xml ) Need Help??

eyepopslikeamosquito has asked for the wisdom of the Perl Monks concerning the following question:

At work, we have a number of long-running scripts. It has been suggested we turn them into modules.

These long-running scripts tend to have a similar structure: they write a running commentary of what they are doing to stdout (via print); they write anything fishy to stderr (via warn); and they die if they encounter a nasty error.

I am eager to learn good ways, general guidelines even, re using print, warn and die inside Perl modules. Error handling, in particular, seems a tricky area of module design. General guidelines and/or examples of well-designed CPAN modules I can study are most welcome.

For the sake of definiteness, suppose we want to call the module in such a way that it never dies and so that all output emitted by the module is written to a log file and to STDOUT simultaneously. I suppose we could try something like this:

sub tee_print { print MYLOGFILE $_[0]; print $_[0] } eval { local $SIG{__WARN__} = \&tee_print; my $h = MyModule->new(PrintHandler => \&tee_print); $h->method($params) or tee_print("oops: " . $h->errstr()); }; if ($@) { tee_print("error: $@") }

Here we have a PrintHandler attribute (use print by default, allow user to override) and an errstr method to return the last error encountered by the module. We could further try this:

my $h = MyModule->new(PrintHandler => \&tee_print, WarnHandler => \&tee_print, ErrMode => 'return'); $h->method($params) or tee_print("oops: " . $h->errstr());

Here we added new WarnHandler and ErrMode attributes, where ErrMode is modelled after Net::Telnet's errmode attribute.

Replies are listed 'Best First'.
Re: Turning a script into a module
by sauoq (Abbot) on Jul 17, 2003 at 05:16 UTC
    At work, we have a number of long-running scripts. It has been suggested we turn them into modules.

    I'd suggest a different approach. Go through your scripts to see what they have in common that can be extracted to a set of modules. Write the modules and then re-write your scripts to use those modules. As you say that the scripts have a "similar structure", it is likely you'll find a lot of code duplication. It's that duplication that you want to get rid of.

    For the sake of definiteness, suppose we want to call the module in such a way that it never dies and so that all output emitted by the module is written to a log file and to STDOUT simultaneously.

    While you are overhauling your scripts to take advantage of code reuse, be on the lookout for opportunities to reuse code that has already been written. For example, IO::Tee should help you with teeing your output.

    -sauoq
    "My two cents aren't worth a dime.";
    
      Excellent suggestion, ++sauoq.

      When you're ready to build your module, have a gander at Simple Module Tutorial by tachyon. Full of useful guidelines and information.

      Cheers!

      MrCromeDome

Re: Turning a script into a module
by yosefm (Friar) on Jul 17, 2003 at 06:56 UTC
Re: Turning a script into a module
by barbie (Deacon) on Jul 17, 2003 at 08:43 UTC
    Rather than thinking about warn and die when something goes wrong, think about return codes.

    If something goes horribly wrong, I usually return undef, then the caller can check whether anything was returned and handle it as it wishes. In some cases I also setup an internal error code and/or error message (ERRNO, ERRMESS), which can be accessed like Package::ERRNO. This then puts the reliance on the caller to handle the errors as they see fit.

    Regards having a PrintHandler, passing that as you have seems fine, but if this is just for warnings and errors, I would personally use the return codes. Then again if this is for own use then it probably isn't an issue, if it was for CPAN you might want to consider that others might not want to print anything at all.

    --
    Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/

      If you want to see nothing at all, you can use:

      PrintHandler => sub {}

      Many of the methods are very long-running, so most users want feedback about their status (and that the machine has not hung). A PrintHandler callback function is the best I have thought of so far. I suppose a GUI front-end could display the status message in a window.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://275110]
Approved by crouchingpenguin
Front-paged by adrianh
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2024-03-19 09:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found