read-file-name error-handling problem

read-file-name error-handling problem

[Noah Friedman]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1016 bytes --]

Speaking of read-file-name calling conventions, I'm running into a case
where errors from read-file-name are not caught by condition-case even when
they should be.  I believe that the code snippet below should print a
message in the echo area instead of going into the debugger.

This happens building from the cvs trunk as of last night, but I first
noticed it a few weeks ago but was too busy to produce a smaller test case.
This test case attempts to call read-file-name in an xemacs-compatible
fashion but trap errors from that, and is failing.  (I first ran into this
problem with VM.)

To demonstrate the bug, load this file and run M-x foo, then type some
partial file name in your current working directory and then try to
complete it, e.g. I have a directory called "bin" in my home directory, and
if I type M-x b<TAB>, I get thrown into the elisp debugger.  The backtrace
is attached below.

No fix yet, but I thought I'd report it in the meantime in case someone
else immediately recognizes the problem.


[-- Attachment #2: foo.el --]
[-- Type: text/plain, Size: 232 bytes --]

(setq debug-on-error t)

(defun foo ()
  (interactive)
  (let ((foo-history '("~/foo")))
    (condition-case err
        (read-file-name "Foo: " "~/" nil nil nil foo-history)
      (error
       (message "caught error: %s" err)))))

[-- Attachment #3: backtrace.txt --]
[-- Type: text/plain, Size: 594 bytes --]

Debugger entered--Lisp error: (invalid-function ("~/foo"))
  ("~/foo")("~/bin/")
  read-file-name-internal("~/bin/" "~/" lambda)
  minibuffer-complete()
* call-interactively(minibuffer-complete)
  read-file-name("Foo: " "~/" nil nil nil ("~/foo"))
  (condition-case err (read-file-name "Foo: " "~/" nil nil nil foo-history) (error (message "caught error: %s" err)))
  (let ((foo-history ...)) (condition-case err (read-file-name "Foo: " "~/" nil nil nil foo-history) (error ...)))
  foo()
* call-interactively(foo)
  execute-extended-command(nil)
* call-interactively(execute-extended-command)

Re: read-file-name error-handling problem

[Richard Stallman]

I figured out the cause of this.  Qerror in the handlerlist->handlers
is used as a special signal meaning "handle all signals and let the
debugger run".  This was supposed to apply only to
internal_condition_case, but in fact it applied to condition-case
also.

It is not hard to fix this; the only worry is whether any Lisp code
depends on this.  (Though the Lisp manual does not describe this
behavior.)

Re: read-file-name error-handling problem

[Richard Stallman]

I figured out the cause of this.  The minibuffer's recursive edit
comes inside your condition-case, and it established an environment
where the debugger is allowed to run.

It may not be the result that you want, but I am not sure it is a bug.

Re: read-file-name error-handling problem

[Noah Friedman]

>I figured out the cause of this.  The minibuffer's recursive edit
>comes inside your condition-case, and it established an environment
>where the debugger is allowed to run.
>
>It may not be the result that you want, but I am not sure it is a bug.

How do I avoid it?

Re: read-file-name error-handling problem

[Richard Stallman]

    >I figured out the cause of this.  The minibuffer's recursive edit
    >comes inside your condition-case, and it established an environment
    >where the debugger is allowed to run.
    >
    >It may not be the result that you want, but I am not sure it is a bug.

    How do I avoid it?

You would have to solve your problem differently.  Sorry, but I'd
rather not work on this.