On Sep 26, 2017, at 1:43 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> On 26 Sep 2017, at 9:17pm, Guy Harris <g...@alum.mit.edu> wrote:
>
>> 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!)
>
> My support staff are allowed to look things up.
Just don't force them to ask, *before* the look it up, whether the user's
running Linux or macOS or FreeBSD or Solaris or Windows.
> My users, when faced with a result which means "permission error" will
> probably grant all permissions to all apps and all users because that’s the
> simplest way to make a permission error message go away. My users don’t
> understand the Posix permission model, because they’re not computer experts,
> they are financial sector specialists, or psychologists, or tailors. I don’t
> want them thinking about computer problems. If they knew enough about
> computer problems to fix a permission problem the right way, they wouldn’t be
> paying me.
And, when faced with a result that says "disk I/O error", your users will
probably think their disk is broken and take it in to be fixed.
So:
for errors where the user *can* perhaps fix the problem, such as "out
of file system space" (which already has its own error) and "out of disk quota"
(which doesn't, and which is different from "out of file system space"), tell
the user what the problem is (and, at the application level, offer a suggestion
such as "delete some of those cat videos you've saved");
for errors where the user probably *can't* fix the problem, tell them
that there's a problem for which they need to talk to support, and tell them
what to say to the support staff so that the support staff knows that, for
example, a disk hasn't gone bad.
(And there are places where "you don't have permission to do that" *is* the
appropriate thing to tell the user, e.g. if they're trying to open a document
to which they haven't been given read permission, or trying to write to a
document to which they haven't been given write permission, etc.. I suspect
your support staff have better things to do with their time than explain to a
user that they're not allowed to read somebody else's private files.)
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
