On Sep 26, 2017, at 2:22 PM, Jens Alfke <j...@mooseyard.com> wrote: >> On Sep 26, 2017, at 1:57 PM, Guy Harris <g...@alum.mit.edu> wrote: >> >> Which means "for stuff that would be shown to the user, for the user to >> read, either localize your error messages, or make sure your API returns >> error codes that the application can turn into localized error messages". > > Um, that’s what I said. > >> And none of this argues against presenting to the user, in their native >> language, a message saying "you've exceeded your file system quota", if that >> is, in fact, what happened. > > This thread isn’t about filesystem quotas. Why do you keep bringing them up > as an example?
Because the thread brings up the general question of folding multiple types of errors into a single error code, and because it's an example of an error you *would* want to show to the user, just as SQLITE_FULL is. >> *don't* tell the user anything that might convince them that their disk is >> failing if you didn't get EIO or the equivalent on some other OS - and don't >> tell them something that, when relayed to tech support, would lead the >> support person to believe that, either. > > As we’ve been saying, error messages produced by SQLite are not meant to be > shown to end users, for all the reasons previously discussed. > > SQLite’s error numbers ought to be sufficiently detailed once you enable > extended error codes, and/or get the OS errno. The original set of error > codes is inadequate to be sure, for historical reasons, but compatibility > rules out breaking that API; that’s why the extended error codes exist. Yes, which is why I wasn't suggesting changing the error codes. I *would* suggests an additional API to get a *separate* extended error code, so that if, for example, a write() fails and that failure is turned into SQLITE_IOERR, you can get something that distinguishes EIO from other errors such as EFBIG, EDQUOT, etc.. I would also suggest that the documentation say that, if you don't have to run on a version of SQLite that doesn't support the new API, the new API be used by applications and libraries running atop SQLite in their error-reporting code, rather than, for example, just using sqlite3_errstr(). _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
