Well, the terminology is correct. These *ARE* I/O Errors. The system attempted I/O. It failed. Hence the term I/O Error. It is irrelevant whether the error was caused because the heads on the tape drive need cleaning, access was denied to spool storage, the disk was full, someone yanked the cable out of the disk drive, or the card reader got jammed up. The program attempted to perform an I/O operation (of some kind). That operation failed.
Now it is up to you, the application programmer, to figure out what to do. There are quite a few facilities available to help you do this. SQLite itself has Extended error codes that can help point to where the trouble is. You can ask the Operating System for its abend code. You can sacrifice chickens or baby's or perhaps read the tea leaves. Personally I think we need a reversion to the old days when there were only four status codes: OK, What?, How?, and Where? This is far more effective than niggling over what an error code means. It means there was an error. Full-stop end of sentence, paragraph, page, chapter, section, story and book. There are more than adequate was of determining the nature and localization of the error. Use them. Love them. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Jens Alfke >Sent: Tuesday, 26 September, 2017 21:49 >To: SQLite mailing list >Subject: Re: [sqlite] bug: failure to write journal reported as "disk >I/O error" > > > >> On Sep 26, 2017, at 3:17 PM, Guy Harris <g...@alum.mit.edu> wrote: >> >> It shows a whole bunch of codes, none of which are "something that >distinguishes EIO from other errors such as EFBIG, EDQUOT, etc.". >> >> I'm not asking for something that indicates what xXYZZY method >reported the error. I'm asking for something that indicates what the >underlying problem causing the I/O error is, to the extent that >information is available from the OS, i.e. *why* did the I/O >operation not succeed? > >Yes, you’re right — I hadn’t looked at the definitions of those >extended codes, and they seem … um, not super useful. As a client of >SQLite, I want to know what specifically went wrong, not which >internal bit of SQLite reported the error. > >—Jens >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
