From: Richard Copley <rcopley@gmail.com>
To: 25735@debbugs.gnu.org
Subject: bug#25735: 26.0.50; url-retrieve errors are peculiar
Date: Tue, 14 Feb 2017 21:21:48 +0000 [thread overview]
Message-ID: <CAPM58ogLX4HRp0GLTxpqo+3La_PeVS7CvQif+nyMMPmP94vJbw@mail.gmail.com> (raw)
Within the docstring for url-retrieve, it says: "[...] The
error can be signaled with (signal ERROR-SYMBOL DATA) [...]",
but in current master (grep for ":error" in "lisp/url/*.el") the actual
usage is that ERROR-SYMBOL is `error' and DATA is a list that starts
with a symbol, for example (connection-failed "failed with code 10061"
:host "localhost" :service 80). The docstring hints at something
like this:
(url-retrieve (format "http://localhost/non-existent-resource")
(lambda (status &rest args)
(let ((error-info (plist-get status :error)))
(when error-info
(signal (car error-info) (cdr error-info))))
;;...
))
which ends up calling this:
(signal 'error
'(connection-failed "failed with code 10061"
:host "localhost"
:service 80))
which ends up printing these two lines (including the newline
embedded in a string) to the echo area:
error in process sentinel: peculiar error: "failed with code 10061
", :host, "localhost", :service, 80
Unfortunately the error code itself, `connection-failed', is dropped.
(See print_error_message in "print.c"; if ERROR-SYMBOL is `error' then
the car of DATA, say ERRMSG, is printed if it is a string; if ERRMSG
is not a string then "peculiar error" is printed instead of ERRMSG.)
Please also consider augmenting the docstring with an example of using
the error data. It's a drag for the user to have to work that out
before they are in a position to call url-retrieve!
(There's a tiny example above, but of course it assumes
that DATA has been changed to conform to the docstring.)
next reply other threads:[~2017-02-14 21:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 21:21 Richard Copley [this message]
2019-05-15 6:04 ` bug#25735: 26.0.50; url-retrieve errors are peculiar Lars Ingebrigtsen
2019-05-15 7:01 ` Richard Copley
2019-05-15 7:16 ` Lars Ingebrigtsen
2019-05-15 7:46 ` Lars Ingebrigtsen
2019-05-15 20:59 ` Richard Copley
2019-05-16 3:59 ` Lars Ingebrigtsen
2019-05-16 8:11 ` Richard Copley
2019-05-15 7:17 ` Lars Ingebrigtsen
2019-05-15 7:19 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPM58ogLX4HRp0GLTxpqo+3La_PeVS7CvQif+nyMMPmP94vJbw@mail.gmail.com \
--to=rcopley@gmail.com \
--cc=25735@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).