Re: with-url

[Dmitry Gutov <dgutov@yandex.ru>]

On 29.12.2016 03:41, Lars Ingebrigtsen wrote:

> That is, you can put the error handling form at the start if the first
> symbol is `error' in that form.  Well, it can't be `error', but perhaps
> `url-error'.  Or...
>
> Opinions?  :-)

I think you're trying to magic it up too much, by adding error handling 
forms to the macro. Personally, I'd prefer to use condition-case to 
handle errors.

Of course, that will require a new error type (or several) to be defined.

That usage conflicts with asynchronous requests, though. More on that 
later (*).

Another thing to note is that a 404 status should be an error for some 
applications, but others would prefer to treat all statuses the same, 
avoid following redirects, etc, and parse the response headers and body 
anyway. So whether `with-url' should signal an error in those cases, 
should probably be governed by another keyword argument. In "serious" 
libraries, in e.g. Ruby, we make this choice using wrappers, like 
client-side middleware.

Something else I take an issue with, is with `with-url' being a macro. 
:) That violates The First Rule of Macro Club.

I think we can do without, by using one of the more traditional control 
flow solutions. First of all, the fact that `url-retrieve' uses a 
callback is one of its lesser problems. The arguments that the callback 
gets passed are a much bigger one. So we would stop at fixing just that.

The other options are:

1) Return a Promise value. Emacs could use a standardized Promise 
structure in other places, too.

2) Basically require to use the newly-introduced threads for asynchrony. 
The library would suspend the current thread and resume it when 
something happens (a response or an error). Someone should investigate 
the validity of this approach, but the good news is, it can be layered 
on top of (1) later. This option can also be compatible with using 
`condition-case' to handle errors (*).