Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

print or die?

by molecules (Monk)
on Mar 14, 2014 at 12:49 UTC ( #1078322=perlquestion: print w/ replies, xml ) Need Help??
molecules has asked for the wisdom of the Perl Monks concerning the following question:

Several years ago I "learned" somehow that in Perl we should theoretically check all print statements, because there could be funny system problems like a full disk or other things that we otherwise wouldn't know about.

But behold, I was told, autodie will take care of all of that print checking for you. THIS IS NOT TRUE. Just now I read in autodie's documentation on CPAN that it specifically does not check print.

So, how important is checking print statements? I assume it would depend on the application and/or system. Once in a blue moon, one of the cluster environments that I use has funny file writing issues (which err on the side of not writing), so it is something I worry about.

Comment on print or die?
Select or Download Code
Re: print or die?
by robby_dobby (Monk) on Mar 14, 2014 at 13:21 UTC
    Hello molecules,

    I think there may be a better way to do this (other more knowledgeable monks here would chime in) - but have you looked at sigtrap pragma? Adding a die to every print seems kludgy to me.

    Normally, when you have a full disk, you'd encounter a ENOSPC on *nix systems. If you're specifically looking for this signal, you can install an handler to trap it and break out. Otherwise, you can use a 'catchall' untrapped handler on other signals (Do note that this can modify behaviour on other signals that are supposed to do their work :-)).

    There may well be a better way to do this...

      ENOSPC is a return value from a system call, not a signal; so you can't trap it with a signal handler. (The only exception to this being SIGPIPE when writing to a closed pipe or socket.)

      Dave.

        Thank you - I was waffling between signals and errnums. My thinking was, ENOSPC is an errnum from a syscall (usually write) and if print used write under the hood, we would see this error code on a full disk.
Re: print or die?
by Anonymous Monk on Mar 14, 2014 at 13:37 UTC

    So, how important is checking print statements? I assume it would depend on the application and/or system. Once in a blue moon, one of the cluster environments that I use has funny file writing issues (which err on the side of not writing), so it is something I worry about.

    well, if user quotas and harddisk free space aren't monitored routinely (like hourly or daily or weekly) then checking print statements becomes more important

    see also Detecting write errors (disk full, bad media)

Re: print or die?
by fishmonger (Pilgrim) on Mar 14, 2014 at 14:20 UTC

    I've never felt the need to test every print statement when writing to files and so far I've never come across a situation where the print statement failed, but there are rare cases where it can occur.

    If I were going to go down that path, I'd write a sub (lets call it printing) that accepted at least 2 parameters; the first being the filehandle and the rest the data to be printed. Then do the print statement and apply whatever error handling I deemed appropriate (warn or die), which would probably also include the use of the caller() function.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1078322]
Approved by vinoth.ree
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (11)
As of 2014-09-01 15:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (14 votes), past polls