Why should interactive search results raise errors?

Why should interactive search results raise errors?

[Lennart Borgman]

Some interactive search functions raise errors when no hit is found. It 
is quite annoyning if you have set debug-on-error to t. Is there any 
reason why this functions raises errors in this cases? Can that be used 
for anything?

An example is the function in the menu bar: Edit - Search - String 
Forward. As far as I can see this in only meant to be run interactively. 
The same goes for viper-search-next.

It would in my opinion be more convenient if these functions just return 
nil and showed a message when a search fails. Would it not be a good 
convention for interactive search functions in Emacs?

Re: Why should interactive search results raise errors?

[Chong Yidong]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Some interactive search functions raise errors when no hit is
> found. It is quite annoyning if you have set debug-on-error to t. Is
> there any reason why this functions raises errors in this cases? Can
> that be used for anything?
>
> An example is the function in the menu bar: Edit - Search - String
> Forward. As far as I can see this in only meant to be run
> interactively. The same goes for viper-search-next.
>
> It would in my opinion be more convenient if these functions just
> return nil and showed a message when a search fails. Would it not be a
> good convention for interactive search functions in Emacs?

Probably the better thing to do is to add the error to
debug-ignored-errors.

Re: Why should interactive search results raise errors?

[Lennart Borgman]

Chong Yidong wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Some interactive search functions raise errors when no hit is
>> found. It is quite annoyning if you have set debug-on-error to t. Is
>> there any reason why this functions raises errors in this cases? Can
>> that be used for anything?
>>
>> An example is the function in the menu bar: Edit - Search - String
>> Forward. As far as I can see this in only meant to be run
>> interactively. The same goes for viper-search-next.
>>
>> It would in my opinion be more convenient if these functions just
>> return nil and showed a message when a search fails. Would it not be a
>> good convention for interactive search functions in Emacs?
>>     
>
> Probably the better thing to do is to add the error to
> debug-ignored-errors.
>   
Oh! Thanks. I was just going to invent that one. How nice it is there 
already ;-)

I still believe that interactive search commands should not raise 
errors. However I think adding these commands now to 
debug-ingnored-errors is the better solution now. Could we please do 
that now?

Re: Why should interactive search results raise errors?

[Stefan Monnier]

> It would in my opinion be more convenient if these functions just return nil
> and showed a message when a search fails. Would it not be a good convention
> for interactive search functions in Emacs?

I think the better answer is to create a new error class called `user-error'
which would be then added to debug-ignored-errors.  Then we can replace most
elements of debug-ignored-errors by changing the signalling code so as to
signal a `user-error' rather than an `error'.

But that's for post-22.


        Stefan

Re: Why should interactive search results raise errors?

[Lennart Borgman]

Stefan Monnier wrote:
>> It would in my opinion be more convenient if these functions just return nil
>> and showed a message when a search fails. Would it not be a good convention
>> for interactive search functions in Emacs?
>>     
>
> I think the better answer is to create a new error class called `user-error'
> which would be then added to debug-ignored-errors.  Then we can replace most
> elements of debug-ignored-errors by changing the signalling code so as to
> signal a `user-error' rather than an `error'.
>
> But that's for post-22.
>
>
>         Stefan
>   
Yes, that is good.

Re: Why should interactive search results raise errors?

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Some interactive search functions raise errors when no hit is
> found. It is quite annoyning if you have set debug-on-error to t. Is
> there any reason why this functions raises errors in this cases? Can
> that be used for anything?

If you include the search in a keyboard macro, it will terminate the
macro if you repeat it "forever".

Perhaps it should only signal an error if executed from a kbd macro?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Why should interactive search results raise errors?

[LENNART BORGMAN]

From: storm@cua.dk (Kim F. Storm)

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
> > Some interactive search functions raise errors when no hit is
> > found. It is quite annoyning if you have set debug-on-error to 
> t. Is
> > there any reason why this functions raises errors in this cases? Can
> > that be used for anything?
> 
> If you include the search in a keyboard macro, it will terminate the
> macro if you repeat it "forever".
> 
> Perhaps it should only signal an error if executed from a kbd macro?

A good idea in my opinion.

Re: Why should interactive search results raise errors?

[Miles Bader]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:
>> If you include the search in a keyboard macro, it will terminate the
>> macro if you repeat it "forever".
>> 
>> Perhaps it should only signal an error if executed from a kbd macro?
>
> A good idea in my opinion.

This behavior has been part of Emacs for so long that it seems very
risky to just change it now (and the reasons for the suggested change
pretty obscure).

Also, making non-display behavior dependent on being in a keyboard macro
is pretty ugly; Stefan's solution is a far cleaner way to handle the
"debugger problem."

-Miles
-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: Why should interactive search results raise errors?

[Richard Stallman]

    I still believe that interactive search commands should not raise 
    errors. However I think adding these commands now to 
    debug-ingnored-errors is the better solution now. Could we please do 
    that now?

I see no reason to change this.  Lots of commands signal errors when
they can't do what they are asked to do; why shouldn't these?

    I think the better answer is to create a new error class called `user-error'
    which would be then added to debug-ignored-errors.  Then we can replace most
    elements of debug-ignored-errors by changing the signalling code so as to
    signal a `user-error' rather than an `error'.

That is not necessarily a bad idea, but I am not sure whether it is
really possible to distinguish "user errors" from other errors at the
level of calls to `signal'.

`debug-ignored-errors' does make an attempt to distinguish which
errors are _probably_ user errors, but it cannot really know,
and sometimes this criterion gets the wrong answer.

Re: Why should interactive search results raise errors?

[Lennart Borgman]

Richard Stallman wrote:
>     I still believe that interactive search commands should not raise 
>     errors. However I think adding these commands now to 
>     debug-ingnored-errors is the better solution now. Could we please do 
>     that now?
>
> I see no reason to change this.  Lots of commands signal errors when
> they can't do what they are asked to do; why shouldn't these?
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?

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.

Re: Why should interactive search results raise errors?

[Stefan Monnier]

>     I think the better answer is to create a new error class called
>     `user-error' which would be then added to debug-ignored-errors.
>     Then we can replace most elements of debug-ignored-errors by changing
>     the signalling code so as to signal a `user-error' rather than an
>     `error'.

> That is not necessarily a bad idea, but I am not sure whether it is
> really possible to distinguish "user errors" from other errors at the
> level of calls to `signal'.

Clearly, the distinction between the two is only based on an expectation of
the context in which the function will be used.  So it's a heuristic and can
fail, but it on the flip side it also documents some of the intention behind
the code.
I think of it mostly as a way to clean up the debug-ignored-errors list.


        Stefan