Agent and wrong passwords

Agent and wrong passwords

[Eric Knauel]

The nntp server I'm using is password protected, so the first time I
enter a group on that server I need to provide username and password
in the minibuffer.  This works fine in plugged and unplugged mode.

However, if I do `M-x gnus-agent-fetch-session RET' and the password
is wrong the agent says "Error Wrong type argument: stringp,
nil. Continue? (y or n)".  Is this what the agent is intended to say?

-Eric
-- 
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee" (Albert King)

Re: Agent and wrong passwords

[Kevin Greiner]

Eric Knauel <knauel@informatik.uni-tuebingen.de> writes:

> The nntp server I'm using is password protected, so the first time I
> enter a group on that server I need to provide username and password
> in the minibuffer.  This works fine in plugged and unplugged mode.
>
> However, if I do `M-x gnus-agent-fetch-session RET' and the password
> is wrong the agent says "Error Wrong type argument: stringp,
> nil. Continue? (y or n)".  Is this what the agent is intended to say?

Eric,

I've been looking into this and I believe that I now understand that
is happening.  When the authentication fails, the backend attempts to
throw an error.  The intent was probably (this is speculative as I
haven't found this code) to call (error msg) to signal the error.
This is the right thing to do except that it requires that msg be
bound to a string.  If msg is nil, the error function itself throws a
"wrong type argument" exception.

I believe that this is what you experienced.  I'm inlining a code
fragment to demonstrate.

(let ((msg "Good Message. Change msg to nil to break"))

(condition-case err

(progn
;; the body where something interesting happens
(error msg))

(error ; This isn't the function error but rather the types of 
       ; errors handled by this signal handler.
(message "Error %s.  Continue? " (error-message-string err)))))

If you eval this fragment, you can see the expected prompt issued by
the agent.  On the other hand, if you change the Good Message string
to nil, you can get the exact same prompt as you originally reported.

If you would do one test, it would make it possible to fix this error.

Start gnus.
M-: (setq debug-on-signal t)
M-x gnus-agent-fetch-session with a bad password

This will throw you into the debugger showing where the origin of the
original (error nil) expression.  Please post this stacktrace.

Kevin