in reply to Re^4: unquoted string error??!!
in thread unquoted string error??!!

Ok, you're right, there is a warning here. I think though that the actual code closed another handle that was already closed from some other function. And if there was a warning, it would have been in a log file with lots of other output (though probably at the top of the file). And autodie may caught it also, but we're using 5.8.8, so autodie is not in core, but since we tend to trap and email errors, that would probably require eval, and if you think I have trouble getting people to use lexical handles (or AAH's which happen to be stored in lexical variables...), just watch me try to get anyone to use eval.

So sure, there are lot's of ways to catch this bug, but I think the simplest way to catch it dead in it's tracks at 'compile' time would have been to use a lexical handle.

OR, say the subroutine had 2 handles, and you closed one of them twice. The other would be closed when the sub exited, so you'd still have 'bad' code, but no bug.

Replies are listed 'Best First'.
Re^6: unquoted string error??!!
by JavaFan (Canon) on May 05, 2011 at 11:16 UTC
    And if there was a warning, it would have been in a log file
    It's a frigging compile time warning! You mean, you're even skipping the "see whether it compiles" step before shipping?
    OR, say the subroutine had 2 handles, and you closed one of them twice. The other would be closed when the sub exited, so you'd still have 'bad' code, but no bug.
    So, your claim is that you ought to be using "lexical filehandles" because if you are in the habit of ignoring warnings (including compile time warnings), ignoring return values from close because there may be a situation where Perl does the thing you wanted it to do at the right time? Sounds like a pretty weak argument to me.
[reply]
[d/l]
Re^6: unquoted string error??!!
by tchrist (Pilgrim) on May 04, 2011 at 18:16 UTC
    If you don’t check return values, don’t blame Perl for errors in your code. Same with C.

    Also, if you close a file twice, then that is also an error. You should have checked the return value from close both times — and every time.

    Who closes files without checking to see whether it worked? That’s just begging for catastrophe.

[reply]
[d/l]

      Well, I never said this (the original code anyway) was my code. And at least one other person sometimes closes files without checking the return value :-)

[reply]
        Do you think that is somehow not a bug? It certainly is.

        However, whether it’s a bug only in his code, or a bug in the runtime, is a perfectly reasonable point. Anything that is absolutely required to guarantee correct behaviour is too important to be left up to programmers to forget to do correctly, and so should so should be taken care of for them.

        We’ve considered a DESTROY method that would detect and report this, fatally if autodie is enabled. There is never any reason to ignore the return of open, nor likewise that of close, because doing so makes your program just as unacceptably unreliable as a program that has “only a small” race condition would be.

        If Perl is going to go sneaking behind your back to run a close, then it needs to do it the right way, not the wrong way.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom