I included an exit method so that I could easily log a message and exit with a specified error code and the same time. In an early project with this module, I found that I was regularly logging some message and then croaking with the same message. This made for an ugly mess and much duplicated code. To fix this, I added the exit method.

While I can see your point about automatically opening the file, something about it bothers me. I could make it possible to control open and close in a call to the constructor. But, since I chose not to use named parameters in the method calls, at that puts a real constraint on how many parameters each method can take without becoming cumbersome. I'd have to add two parameters to new. I hate functions and methods with long parameter lists, so I have say I can't agree to this one. I also feel like there is a built-in expectation that you have to open a file to use it. This module is intended to be a rather thin wrapper around a file handle. Of course it would be a simple matter to subclass and add this feature if one desired it.

Your points about auto-opening the handle and what it means to be simple really do emphasize brian_d_foy's point about good naming.

Your point about closing on a DESTROY is well taken. I've mostly used this on windows systems, which don't choke up if you fail to close a filehandle. But it could be used on other systems that might have that failing. I really should add a DESTROY method.