Re: Cleaning up filehandles and directoryhandles

But I get the impression that fileno() doesn't work for directory handles.

So don't use it. close the filehandle unconditionally. If it's already closed, close may indicate an error by returning false, which you can ignore. In fact, you already ignore errors returned by close.

$_->close()
   foreach @openedFileHandles;
[download]

On the more general topic, this seems like a whole lot of work for something that should be handled by scope. File and directory handles are automatically closed when they go out of scope. It's much easier and safer to limit the scope of the handles than doing what you are attempting.

and I open my files like

And finally, it's very poor design for openFile's arguments to be in the reverse order of open's. Seeing that erodes my trust in the module, to say the least.

Comment on Re: Cleaning up filehandles and directoryhandles Select or Download Code

Replies are listed 'Best First'.
Re^2: Cleaning up filehandles and directoryhandles by anthski (Scribe) on Aug 10, 2005 at 07:51 UTC
So don't use it. close the filehandle unconditionally. Fair enough. I was trying to find a correct way to do things (in admist what seems to be a few mistakes). It doesn't exactly feel right that there is a method for checking if a file is open, but not a directory, and that it's good form to just close on everything, even if it isn't actually open. And finally, it's very poor design for openFile's arguments to be in the reverse order of open's. Seeing that erodes my trust in the module, to say the least. A fair call. The reversed order of openFile's arguments was done to match the order of argument's to FileHandle->new(). Thanks for the advice and I'll take a 'bigger picture' approach and match up openFile() to open().	[reply]

Replies are listed 'Best First'.

Re^2: Cleaning up filehandles and directoryhandles
by anthski (Scribe) on Aug 10, 2005 at 07:51 UTC

So don't use it. close the filehandle unconditionally.

Fair enough. I was trying to find a correct way to do things (in admist what seems to be a few mistakes). It doesn't exactly feel right that there is a method for checking if a file is open, but not a directory, and that it's good form to just close on everything, even if it isn't actually open.

And finally, it's very poor design for openFile's arguments to be in the reverse order of open's. Seeing that erodes my trust in the module, to say the least.

A fair call. The reversed order of openFile's arguments was done to match the order of argument's to FileHandle->new(). Thanks for the advice and I'll take a 'bigger picture' approach and match up openFile() to open().

[reply]