bug#11999: 24.1.50; New Info file suffix ".info" breaks `Info-find-node-2'

[Drew Adams]

> > I will try to help with the name, once you make clear what 
> > the defining characteristics are: in what cases should this
> > be used?  Whatever is not included in those characteristics
> > should fall to plain `error'.
> 
> I already explained it: user-error is for errors which are 
> not caused by bugs in the code (i.e. they're caused by
> manipulation mistakes, or problems in the environment such
> as missing files, ...).

I see.  So it is instead the behavior of `error' that you are defining in a
clear way, and `user-error' that is the catchall: everything else.

I think that is a mistake, for the reason I gave earlier: If you need later to
carve out a new class, it logically would come from the catch-all, which
according to your classification is what you have called `user-error': anything
that is not a code error.  It makes much more sense, IMHO, for `error' to be the
catchall.

But you're the boss.  Given that approach, I would propose these names:

* `code-error': errors that indicate a bug in the code
* `other-error': any other error

`code-error' errors should presumably never happen.  That is, we normally try to
implement code that we do not _expect_ will ever throw a `code-error' error.

Given such a renaming, you need to decide how to handle the traditional `error'.
Would it be defaliased to `code-error', thus limiting the traditional scope
considerably, or defaliased to `other-error', which is more in line with what it
has been.

IOW, given your characterization, I do not think it is a narrow category of
"user" error that is new.  What is new, it seems to me, is the narrow category
of code errors.

HTH.