Re^5: using lexically scoped variable as a filehandle

If a close fails, I surely want to die, as this is an unrecoverable error.

Absolutely not!

I could just warn, but then? what next?

It obviously depends upon what else your program is doing, but a few ideas:

Close your DB handle. Possibly rolling back the last transaction.
Delete the file that failed to close properly.
Truncate the file back to the possition you recorded when you opened it.
Close any communications channels that you have open. Possibly with a failure status.
Sleep for a second and re-try the close in the hope that some other process might have freed the one block of disk space you need to allow you file to be written in it's entirety.
system qq[del $ENV{ TEMP }\*.tmp]; and re-try.

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^5: using lexically scoped variable as a filehandle Download Code

Replies are listed 'Best First'.
Re^6: using lexically scoped variable as a filehandle by misterwhipple (Monk) on Feb 21, 2007 at 21:21 UTC
A question, more for curiosity than utility: Let's say I `use Fatal qw{ close };` which changes the behavior of `close` to throw an exception on failure instead of returning `false`. Let's also say the automatic (invisible) end-of-scope `close` failed. Would the exception still be thrown? If yes, is this useful for improving the context-related situation?	[reply] [d/l] [select]
Re^7: using lexically scoped variable as a filehandle by BrowserUk (Patriarch) on Feb 21, 2007 at 22:28 UTC
I'm the wrong person to ask as I've never felt the need for Fatal. I've also tried on several occasions to actually create the situation where a write to a buffered file, passed the end of available disk space, succeeds, in order to try and provoke close failure: `!dir I:*;; Volume in drive I is RAMDISK Volume Serial Number is 7FFF-FFFF Directory of I:\ 2007-02-21 22:12 20,971,522 fred 2007-02-21 22:14 985,570 fred2 2 File(s) 21,957,092 bytes 0 Dir(s) 1,024 bytes free open O, '>', 'I:fred3';; select O; $\|++; select STDOUT;; print O chr( 0 ) x 1000 or warn $!;; print O chr( 0 ) x 25 or warn $!;; No space left on device at (eval 6) line 1, <STDIN> line 5.` [download] ... but as you can see, but this is always detected when writing. Maybe this used to occur on old filesystems, but I cannot find a way to make it happen now, so I cannot determine an answer for you that way either. Can close fail for any other reason? 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re^6: using lexically scoped variable as a filehandle by shmem (Chancellor) on Feb 21, 2007 at 18:27 UTC
It obviously depends upon what else your program is doing That's the point here - context :-) It depends on the type of file, of it's importance, of whatever the whole program is about - but if I want to die on a failed open (and not retry, close & retry, re-initialize handles, etc, whatever, or else), I almost certainly want to die on a failed close as well. But, that depends... my point is, if a close fails, something very unusual,weird and unforeseen is happening for which I don't have automatic recovery strategies, and I'd better not do anything beyond the fact. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]