On Tue, Sep 26, 2017 at 01:37:42PM -0700, Jens Alfke 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.) And there are plenty of messages that are much > less understandable to a lay user than the one you picked out.
They could be. And regardless, more detail in the error _code_ is better for the applicaton developer. EIO is definitely an I/O error. Could be all sorts of things. E.g., you're using iSCSI and the network is timing out. ENOSPC is very, very different. Reporting ENOSPC as an I/O error means that the app or the user must now use df(1) or strace(1) or similar to work it out, when SQLite3 could just have reported that the FS is full. Ditto EDQUOT. EROFS is also very different. And so on. These are ancient error codes. > > 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!) > > On the contrary, error numbers are a lot easier for support. They’re > independent of locale, they don’t get re-worded from one version of > the app to the next, and they’re very short and easy to dictate over > the phone. Of course, these shouldn’t be the primary error information > given to the user! But the user-level error message should be > something specific to the application, like “an unexpected database > error occurred (19)” instead of "Abort due to constraint violation”. > The number would appear only for support purposes. As long as you can resolve them to symbolic names and/or messages. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
