[Melbourne-pm] Detecting Hardware limits / problems
simon at unisolve.com.au
Wed Jan 26 15:03:40 PST 2005
> Things i can think of.
> Always check the return value of system calls. :) Not really as simple
> as that unfortunately. Failing to open a file for reading _may_ mean
> the hard disk has failed, or that the user has messed up the
> installation of the program. Maybe use some sort of variable to keep
> track of this? On the other hand, i've never seen a seek fail at all,
> and maybe it would only fail if the hard drive failed.
I've found that chekcing the return code of the close() subroutine, (which is
not often bothered with), is invaluable for checking for errors when the
file that was opened is a process, rather than a plain file. In Unixy
environments at least, some unusual error conditions won't be
detected when the "file" is opened with open() but will be detected with
close(). I'm thinking here of pipes failing due to insufficient memory, or
named pipes failing due to lack of disk space. etc....
Can't think of anything else relevant.
Unisolve Pty Ltd - Melbourne, Australia
+61 3 9568 2005
More information about the Melbourne-pm