I'm sorry gentlemen, but the argument has gotten thick and petulant. Every complaint and response is resolving down to a mainframe line of thought (thank God), which few today are willing to accept. That is, the SQLite software is kept compatible with its root. How many System 370 Cobol programs can run on to today's hyper-tech mainframes? All of them. Sqlite was inspired by a need and built at a time when PC's and O/S's were more primitive. It has some flaws from then that are still with us today. Why? Because of compatibility. It is more important for this product to be compatible with its origin because people and machines are dependent on it being that way.
The error system is what it is because it worked back then. Efforts have been made to improve things as far as giving the developer more information to work with and figure things out. The developer knows their version of SQLite and their operating system(s). It's the developer's responsibility to match what SQLite provides given the values available in the environment that it exists in. If the developer's application is going to run atop of Linux, and Windows, and Android, it is the developers job to create their application in a way that is sensitive to them. SQLite is capable of running anywhere. It is not its responsibility for knowing exactly where it is being run. It doesn't function at that layer. If the codes are not enough, the amalgamation is out there. Get a copy and build into it a new layer of error interpretation logic and have it return what is needed by the O/S that is specific to the application's needs and wants. If I'm wrong, I'm sorry. But I got the feeling the original post (the very first) was a tantrum, and no matter what anyone does to sooth the situation is working. It is only getting worse. Again, I apologize for losing my control. On Wed, Sep 27, 2017 at 12:12 PM, Guy Harris <g...@alum.mit.edu> wrote: > On Sep 27, 2017, at 10:00 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > > > On Wednesday, 27 September, 2017 10:39, Guy Harris <g...@alum.mit.edu> > wrote: > > > >> On Sep 27, 2017, at 6:58 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > > > >>> Well, the terminology is correct. These *ARE* I/O Errors. The > >>> system attempted I/O. It failed. Hence the term I/O Error. > > > >> Just don't call it a "disk I/O error". > > > > Well, maybe. However the I/O that had the error was associated with a > disk operation (as opposed to a "Video I/O Error", or a "Cardpunch I/O > Error", "Printer I/O Error", etc.). > > Actually, if it had occurred on my machine, it wouldn't have been > associated with a disk operation; should the application check where the > data is stored and say "flash memory I/O" error if appropriate? :-) > > The point is that the *disk* isn't particularly relevant to some possible > errors - the problem isn't with the *disk*, which reported no error, the > problem is with something in the *file system*, such as the amount of space > available, the permissions on files, etc.. > > >>> 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. > > > >> I.e., SQLITE_IOERR is equivalent to -1 as a return from various UN*X > >> system calls, so that, when a program sees it, it needs to get > >> further error information, such as an errno value, to deal with the > >> error and, if necessary, to report it. > > > > Yes. An I/O operation of some sort was attempted. That I/O operation > involved some sort of "disk" access. That operation failed with an error. > > ...and the next step is to determine what the exact error was. > > >> So it *is* relevant to what to do next. > > > > Well, in the same sort of way as the message from attempting to send > Snail mail "Mail Undeliverable" is relevant to what to do next. You know > that the error was related to the delivery of the postal item just as the > "Disk I/O Error" indicates that an I/O operation that involved a disk > operation failed with an error. > > > > In both cases you need to query for the underlying error condition in > order to determine what to do. > > Well, in the first case, the postal service may well say more than just > "Mail undeliverable", such as "no such person at that address", "no such > address", etc.. > > > So in that sense it is relevant to what to do next -- you need to query > for more particulars. This is opposed to say a "Syntax Error" in which it > is pretty clear that the error is a mis-formed statement. > > Yes, but even in *that* case, it's often possible to say, for example, > "there's no operator between the operands "foo" and "bar"" rather than just > "syntax error". > _______________________________________________ > 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
