Re^6: Scoping question - will file handle be closed? (close errors)

If I have no logical recovery step for "incomplete data", then I will just warn when close fails.

And that is really the point I'm arriving at; and your clarification of some of possibilities has taken me ever closer.

Basically, there is never a logical recovery step; because the actually failure that gets reported by close may have happened hours ago; and because the range of possibilities is so diverse; and because it would be literally impossible to program a recovery for the vast majority of them.

So, (IMO) the only logical step would be to modify close so that it automatically logged any errors.

It ought be able to extract filenames from handles, ips/socknums from sockets etc. and generally produce a much more detailed account of the failure than user code could hope to do.

And it would relieve the programmer from that burden. I guess I would like an autowarn rather than autodie pragma.

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.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re^6: Scoping question - will file handle be closed? (close errors)

Replies are listed 'Best First'.
Re^7: Scoping question - will file handle be closed? (autowarn) by tye (Sage) on Jul 15, 2015 at 18:33 UTC
modify close so that it automatically logged any errors Yes, I think that would be better behavior, especially when close is called in a void context (like an "autowarn", like you said). The history of Perl internals is mostly to return success indicators but I think autodie is probably a better choice for most of them and autowarn is the best choice for close. Basically, there is never a logical recovery step; because the actually failure that gets reported by close may have happened hours ago; and because the range of possibilities is so diverse Not in my experience, no. The failures are all "incomplete data" and the likely mitigation step I already mentioned: Don't process that incomplete data. Additionally (as I already mentioned), don't mark the data source as "processed" if the protocol has such a step (which many protocols I use do). True, the recovery for the root cause is not something that I expect the software to try to solve, of course. The mitigation is usually just "close ... or die ...". Somewhere up the stack some `eval` takes care of trying to mark the item as failed or just not marking it as successful (and deleting the incomplete file if one was being written to). But my experience matches your expectation: that having close() autowarn would be better than having it autodie. Having close() autodie would more often abort further work when there was no good reason to. - tye	[reply] [d/l]

Replies are listed 'Best First'.

Re^7: Scoping question - will file handle be closed? (autowarn)
by tye (Sage) on Jul 15, 2015 at 18:33 UTC

modify close so that it automatically logged any errors

Yes, I think that would be better behavior, especially when close is called in a void context (like an "autowarn", like you said). The history of Perl internals is mostly to return success indicators but I think autodie is probably a better choice for most of them and autowarn is the best choice for close.

Basically, there is never a logical recovery step; because the actually failure that gets reported by close may have happened hours ago; and because the range of possibilities is so diverse

Not in my experience, no. The failures are all "incomplete data" and the likely mitigation step I already mentioned: Don't process that incomplete data. Additionally (as I already mentioned), don't mark the data source as "processed" if the protocol has such a step (which many protocols I use do).

True, the recovery for the root cause is not something that I expect the software to try to solve, of course. The mitigation is usually just "close ... or die ...". Somewhere up the stack some eval takes care of trying to mark the item as failed or just not marking it as successful (and deleting the incomplete file if one was being written to).

But my experience matches your expectation: that having close() autowarn would be better than having it autodie. Having close() autodie would more often abort further work when there was no good reason to.

- tye

[reply]
[d/l]