George P. wrote: [snip] >> > I noticed that you've said >> > "open () or die()" >> > and >> > "close() or die()" >> > >> > If open fails, the program will kill itself, so >> > the close function will never be called. >> > Therefore there is no need to say "close() or die()" >> >> I don't follow this logic. >> [snip] >> If you are saying that because the file was successfully opened the close >> cannot fail, then this is not correct. Now, it might not fail very >> often, and even when it does you might not care, but then again you >> might, and I normally do. If something goes wrong, I like to know >> about it.
I do too. ;-) > I can't think of any instance when open() will return a true value > and still fail to open an handle to the file. This is neither the point you originally made, nor is it the statement made by the above gentleman. You've managed to confuse _yourself_ at this point. if open returns a true value it won't fail to open the file (since it's already opened the file). no one disputed that. HOWEVER, once the file is open, any number of things could occur that could potentially cause a close() to fail. so, we test for that, too. If something goes wrong on that end, I like my programs to die also, and print me a useful error message advising me of the problem so I can go look and see what happened. I will say that there is a small error in my version of the script that I chose to make, in that it doesn't test for multiple instances of /^Subject:/ but instead skips the remainder of the file upon finding the first one. This is to save time, but it IS based on an (possibly false) assumption. The likelihood is very small though. :-) When you've read enough posts here on nntp.perl.org:perl.beginners and on usenet:comp.lang.perl.misc and seen how many professional perl programmers recommend doing certain things, you quite sensibly get in the habit of doing them. I didn't have to do an explicit close in this case thanks to the loop the open() call was in, however I ALSO chose to do so, because when training a new person (the original poster is a self-admitted newbie :), one hopes to train them to do things RIGHT, even if the code winds up a tad long-winded. Let them learn the shortcuts as they go on. i.e. "as you get used to this, you can effectively leave this part out, but it's good for you to know that it needs to be done, and tested sometimes." It's good programming practice to test these things. period. :) Just because a file opened successfully doesn't mean that it will always close successfully as well. hard drive implosion. network outage. you name it. Q.E.D. 'nuff said. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
