> 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? > *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. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
