On Sep 26, 2017, at 2:16 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> On 26 Sep 2017, at 9:57pm, Guy Harris <g...@alum.mit.edu> wrote: > >> On Sep 26, 2017, at 1:37 PM, Jens Alfke <j...@mooseyard.com> wrote: >> >>>> On Sep 26, 2017, at 1:17 PM, Guy Harris <g...@alum.mit.edu> wrote: >>>> >>>> A user wouldn't know what to do with "you've exceeded your stored data >>>> quota”? >>> >>> A Turkish or Chinese user likely wouldn’t. (SQLite’s error messages are not >>> localized.) >> >> 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". > > No. It means that you should present /your/ error messages to your users, > not error messages generated by SQLite. SQLite is a programmer’s tool. Its > users are programmers, and that’s who its error messages are addressed to. > You should not be letting your users see error message intended for you, and > you should not be making your users worry about what to do about them. "You" in "either localize your error messages, *or* make sure your API returns error codes that the application can turn into localized error messages", refers to SQLite. It ultimately doesn't *need* have have error messages - it could leave that entirely up to the application - but it provides them nonetheless. And there's an "or" in my statement; providing a way to get error codes more fine-grained than SQLITE_IOERR - so that you don't say "disk I/O error" for errors that have nothing to do with a disk reporting an I/O error - is something that the application would need in order to provide an appropriate error to end users and to the people to whom the end user might report an error. And, no, "that error occurred on this operation" is not the sort of fine-grained to which I'm referring. So just provide a way to get an indication of what *particular* type of error generated SQLITE_IOERR - permission error, quota error, actual disk I/O error, etc. - and recommend that this *always* be used for SQLITE_IOERR. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
