in reply to Re^5: guidelines for inline coding
in thread guidelines for inline coding

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

Replies are listed 'Best First'.
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]
      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]

In Section Seekers of Perl Wisdom