Re: Why should interactive search results raise errors?

[Stuart D. Herring]

> If I want to see if there is any hits at all then a failed search is not
> an error. It gives me the information I wanted - whether there are hits
> or not. Why should then this be an error?

The menu eventually calls `search-forward'.  Its doc string begins thus:

  Search forward from point for STRING.
  Set point to the end of the occurrence found, and return point.

If there is no occurrence of STRING, then this function cannot do what it
says it will do, so it must signal an error.  Even if we ignore that it
says it will return point and return nil from it, it has not set point to
anything meaningful, so it should not return normally.

Certainly one could define a function with different semantics -- or a
flag for an existing function.  And we have:

  Optional third argument, if t, means if fail just return nil (no error).
    If not nil and not t, move to limit of search and return nil.

So perhaps you just want `nonincremental-search-forward' to do
(search-forward string nil t)?  That's not unreasonable, but then the menu
and the underlying command would behave differently.  So you could make
the default value for the NOERROR argument depend on whether the function
was called interactively.  But then you have to print some sort of message
when the search fails, and (ding) for backwards compatibility -- but only
when interactive...

It just seems simpler to me to keep the current behavior and use (the
proposed) `user-error' or `debug-ignored-errors' as suggested.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.