print or die?

[molecules]

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.

[fishmonger]

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.

[Anonymous Monk]

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)

[robby_dobby]

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...

[dave_the_m]

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.

[robby_dobby]

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.