Re^5: guidelines for inline coding

And what if warn also fails? Ditto die? Shouldn't you be checking those also?

Both quite likely if the cause of the print (to stdout) is console corruption or failure; or memory exhaustion; or device failure; or ...

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^5: guidelines for inline coding

Replies are listed 'Best First'.
Re^6: guidelines for inline coding by Anonymous Monk on Sep 25, 2014 at 21:12 UTC
... if the cause of the print (to stdout) is console ... ... which is why the example is of a print that isn't to the console. Remember we're talking about print in general here (Laurent_R's example is also printing to a filehandle `$ERRORS`).	[reply] [d/l]
Re^7: guidelines for inline coding by BrowserUk (Patriarch) on Sep 25, 2014 at 21:27 UTC
Even so. If the cause is that there is not enough memory to construct the output string; it doesn't matter where the output is intended to go. And if a file device is full, thus preventing the write, it will be patently obvious where the problem lies because the entire system will have fallen in a heap. And if the problem is a network connection has gone away; or a pipe has closed; or ...; most OS's will display an appropriate and detail diagnostic on the associated console (if there is one) anyway. A diagnostic that is invariably a better diagnostic than most programmers will provide. Let the OS do what it is designed to do. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^8: guidelines for inline coding by Anonymous Monk on Sep 25, 2014 at 21:47 UTC
A diagnostic that is invariably a better diagnostic than most programmers will provide. In fact the example doesn't have warnings turned on, otherwise one would see the very helpful "`print() on closed filehandle $fh`" warning. But there are cases where `STDERR` gets ignored (sometimes technical reasons, sometimes ignorance), so `print "foo" or die;` or `print "foo" or mail_error_report_to_admin();` can be useful. (autodie doesn't check print, but I guess one could do `use warnings FATAL=>'io';`)	[reply] [d/l] [select]