There are physical errors and there are logical errors. If an error is generated from write, it's not unreasonable to classify it as an "output error". From read as an "input error".
There is a lot of sqlite source code that already exists and has been written to work with the current interface. That's probably one of the reasons why extended errors were created, to provide finer granularity. Regardless of whether it is ideal or not, changing sqlite in a way that would break existing code is unlikely to happen. Ultimately it doesn't matter when error codes were added to a given operating system or which predates what. A decision was made in the past. The options are to live with decisions that were made in the past (one I've seen espoused multiple times in this mailing list), come up with an approach that allows old code to work but exposes new information (probably the genesis of extended error codes), or break older code (which I've not seen done deliberately). I'm not trying to tell you that your point is invalid. It makes sense in many ways. Short of a time machine I doubt anything will change (though those decisions are above my pay grade). That being said, I don't know any non-technical users who are going to panic that IOERR means their hard drive is dying specifically because of that text being displayed. Panic perhaps, but not that a hard drive is about to die. Most people I know don't have that level of understanding to correlate IO / ERR / hard drive failure rates. They just think the stupid program is broken and not letting them get their work done. As for the experienced technical people I know (or at least me), their first thought would be to investigate the problem, not to assume their hard drive is failing. On Tue, Sep 26, 2017 at 2:17 PM, Guy Harris <g...@alum.mit.edu> wrote: > On Sep 26, 2017, at 1:05 PM, Simon Slavin <slav...@bigfraud.org> wrote: > >> On 26 Sep 2017, at 8:47pm, Guy Harris <g...@alum.mit.edu> wrote: >> >>> On Sep 26, 2017, at 8:22 AM, Jens Alfke <j...@mooseyard.com> wrote: >>> >>>> The basic error code is SQLITE_IOERR, which just means "Some kind of disk >>>> I/O error occurred” according to the comment. Which is true in this case; >>>> an I/O operation returned an error. >>> >>> But the *disk* didn't - the *operating system* did, so if SQLITE_IOERR >>> really means "Some kind of disk I/O error occurred", it's *not* the right >>> error to return for a *permission* error. >> >> Those error codes were devised in a day when OS error codes were more simple. > > EDQUOT was introduced in 1982, with 4.2BSD; when was SQLITE_IOERR devised? > >> Also please note that those error codes are addressed to programmers. Your >> users should never see the text explanation of the number. Because your >> users wouldn’t know what to do about them. > > A user wouldn't know what to do with "you've exceeded your stored data > quota"? If so, your site has failed to explain to the users that they've > been given a quota, limiting the amount of space on the server that they can > use, and that if they exceed their quota, they either need to delete stuff > they no longer need, move stuff they might *someday* need but don't need > *now* to some archival medium, or ask their system administrator to increase > their quota? > >> At most the user can be shown the number returned to they can quote it in a >> support call. > > The *number* might annoy the support staff; right off the top of your head, > what's the error number for "file system quota exceeded" or "I/O error"? (No > cheating by looking it up in a man page or include file!) > > And, yes, there needs to be *some* way to get the underlying problem reported > to somebody in a position to do something about it - where "the underlying > problem" includes "what did the OS say?" as much as it includes "what SQLite > operation got the error?". > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- Scott Robison _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
