in reply to <rant>CPAN modules failing to check for write errors</rant>

One of the difficulties with lots of error checking is that it is difficult to test. To test code that fails when the filesystem is full, you need a full filesystem.

You can create a small filesystem to overfill for test purposes, but this probably introduces platform dependencies.

Would you want a lot of error checking that is mostly untested?

Does anyone have suggestions for testing code that uses lots of error handling? Or is it all supposed to work perfectly the first time?

It should work perfectly the first time! - toma
  • Comment on Re: <rant>CPAN modules failing to check for write errors</rant>

Replies are listed 'Best First'.
Re: Re: <rant>CPAN modules failing to check for write errors</rant>
by Anonymous Monk on May 30, 2004 at 19:25 UTC
    No, you have to rely on perl returning errors correctly for failed system calls - unless you've just written some nuclear power station control scripts in perl - in that case let me know which power station it was and I'll remember to stay a few thousand miles away from it ;->

    Any, back to the topic in hand - say perldoc -f print: 

    print FILEHANDLE LIST
print LIST
print Prints a string or a list of strings. Returns true if successful.
    If print returns false, that's good enough for me - the important thing is I know the data wasn't written - I can log $! and try to save the data somewhere else etc.

    Camel pg 606 rightly bangs on about always checking failed system calls but it sometimes seems to fall on deaf ears :(

[reply]
      The nuclear power plant software looks like it is written in VB, but it might be MFC. That, along with Flash and Crystal Reports. I hope you feel confident about that!

      For the necessity of testing, I was thinking of the earlier example of the failover of a full nfs filesystem to a new one. That seems like a fair amount of code, and if I wrote it, I would need to test it.

      For example, I was thinking about writing a little test system to see how a module such as File::Slurp handles a full filesystem. Perhaps I could write something like File::Slurp::Failover, which would do the clever nfs failover trick.

      By the way, File::Slurp has some options for error handling. Perhaps it could be used as an example of a good way to handle I/O errors. Or is there a better example of a module that has good I/O error handling?

      It should work perfectly the first time! - toma
[reply]
        The nuclear power plant software looks like it is written in VB, but it might be MFC. That, along with Flash and Crystal Reports. I hope you feel confident about that!

        BOOM !!!!!!!!!!!!!!!!!

        For the necessity of testing, I was thinking of the earlier example of the failover of a full nfs filesystem to a new one. That seems like a fair amount of code, and if I wrote it, I would need to test it.

        Ah yes - I see what you mean. For really critical things I can't see any way round it - generally I assume that any failure from a print is serious enough to switch fs and log whatever was in $!. As you say, it's vitally important that the error handling code does get run before it goes live :)

        Thanks for the info on File::Slurp - I'll have to check it out. No doubt there are modules with good I/O handling on CPAN but I couldnt tell you off hand - another thing to add to my todo list :)

        So I'm going to go off, do a bit more research, and hopefully come back to the monastery with an article and maybe some code for review. Give me a few days and I'll be back :)

[reply]

In Section Meditations