Re^2: Catching errors in closing lexical filehandles

Allowing multiple opens form the same code is a great benefit, perhaps even the greatest, but who said it's the only one? davido mentions a few others, all of which IMHO are valid.

Regarding "you do your error checking on open, not close", this is not quite correct. Close can have errors, e.g. when the file is a pipe that has been closed on the other side.

And regarding die, in the first instance, I was using it as a token for "any appropriate error handling I might choose to apply here". In the second instance, you can (and I often do) achieve protection from termination by catching the die with an eval somewhere up the call train.

Comment on Re^2: Catching errors in closing lexical filehandles

Replies are listed 'Best First'.
Re^3: Catching errors in closing lexical filehandles by TedPride (Priest) on Sep 27, 2004 at 08:11 UTC
Yes, but the point of closing a file is to have it closed, and does it really matter whether it closes from the server side or the client side? Perhaps I should have said no important errors rather than no errors...	[reply]
Re^4: Catching errors in closing lexical filehandles by gaal (Parson) on Sep 27, 2004 at 09:22 UTC
This situation can be indicative of a real applicative failure. perlipc gives the matter some discussion in the secion called "Using open() for IPC".	[reply]