Clojurians Log v2

about http-kit client, how does one generally deal with errors? clj-http has :throw-exceptions true/false. with http-kit, should one check for :errors after deref and then throw yourself?

yes basically. iirc httpkit catches all internal exceptions and propagates them as :error

do you know if it generates an error on certain status codes, like 400?

i believe not. i think :error is only exceptions like SSL/Timeouts/etc... but i will double check

https://github.com/http-kit/http-kit/blob/master/src/org/httpkit/client.clj#L282 shows that :error should be a throwable. see its https://github.com/http-kit/http-kit/blob/master/src/java/org/httpkit/client/IResponseHandler.java. also see the docstring:

"Issues an async HTTP request and returns a promise object to which the value
  of `(callback {:opts _ :status _ :headers _ :body _})` or
     `(callback {:opts _ :error _})` will be delivered.
  The latter will be delivered on client errors only, not on http errors which will be
  contained in the :status of the first.

Right, so:

user=&gt; (type @(c/get "<https://www.gnoffdnjkfnjks.xml>"))
clojure.lang.PersistentArrayMap

wdym? like to do de-structuring/error-handling?

yes

yeah, i suppose there is some forced boiler-plate there

maybe babashka could use a babashka.http-client namespace which removes this boilerplate, making it look like babashka.curl, but based on http-kit instead. while also adding http kit itself for async use.

then it could also become a drop-in replacement for babashka.curl

because you want non-2xx or 3xx to be treated as an error? i guess to be consistent you would want the same semantics for the async callback right?

babashka.http-client would only imitate clj-http with the synchronous interface

if you want async, you can use http-kit directly, but you would have to deal with more boilerplate yourself, which is a reasonably trade-off imo

ah, so they would be different namespaces in other words. you'd just be using http-kit for everything under the hood to reduce implementation complexity

yes

i personally dont mind the httpkit semantics. maybe because i got used to it, but it doesnt seem right to treat errors that happen on the level of SSL or TCP the same as HTTP errors. but for the compatibility reason with the current behavior it makes sense what you propose

Do you have a lot of :error checks in your httpkit code?

we can distinguish errors of status and errors on ssl level using an ex-info

or just re-throw the java exception and use an ex-info for status codes

I usually just want my script to exit with an error in case of a faulty request

i guess if its in the context of a script its one thing, but in the context of a long-running service at the company i work, we want to collect metrics for different response types, including per status code, but also for things like timeout/ssl errors. these can be important for back-pressure/circuit-breaking/retry considerations. but there are very different implications for 4xx vs 5xx vs timeouts vs sslerror which might be dynamic depending on the endpoint you're speaking with. also some apis will return success codes, but then return error messages/internal codes in the response body which must be parsed and considered. might point is in any case, eventually you start getting down into the granularity of status codes and exception/error types anyhow, so the boilerplate becomes unavoidable. but again, probably these considerations are not relevant in the majority of scripting cases and a binary success/error is enough

Any possibility of adding java.security,DigestInputStream to allow computation of hashes from input streams?