Re: with-url

[Dmitry Gutov]

On 21.01.2017 18:44, Lars Ingebrigtsen wrote:

> Nope.  You should only signal an error if you have an error, and getting
> a 404 isn't an error.

Whether 404 is an error or not, depends on an application. And I'm 
saying that as someone with a few years of experience writing web 
applications that do HTTP requests themselves.

Consider the case where an application calls a function foo (which 
implements some sort of abstraction layer), and the said function uses 
with-url.

If foo is supposed to be general purpose (used in different 
applications), it would have to handle errors in a general way, so that 
any of its callers could still handle any kinds of errors, without being 
a macro. I'd rather with-url (or its replacement) was an example of 
doing that already.

> > Something else I take an issue with, is with `with-url' being a
> > macro. :) That violates The First Rule of Macro Club.
>
> Yes, the first rule is "use a macro when it makes sense".

Not really. And macros make sense the most when we add a control flow 
construct, or some sort of definition syntax for a new facility. Neither 
of which is really the case here.

You're basically joining a library function with a control flow 
construct together.

> > 2) Basically require to use the newly-introduced threads for
> > asynchrony.
>
> Using the new threads is a trivial rewrite and doesn't affect the
> signature of the macro.

It could simplify it, by allowing to treat asynchronous code like 
synchronous one.

> Anyway, I think the best option here would be to just have an
> :ignore-errors parameter to `with-url'.  In that case, the body will
> just be evaluated if we get non-error response.

I'm rather more worried about being able to handle errors in an 
asynchronous fashion.

You could say 404 is not an error, but handling it in a similar way to 
all other "actual" errors like "can't resolve the hostname" and 
"connection timeout" can be pretty handy.