This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-01
Channels
- # admin-announcements (3)
- # beginners (25)
- # boot (21)
- # cider (39)
- # cljs-dev (86)
- # cljsrn (20)
- # clojars (4)
- # clojure (70)
- # clojure-canada (1)
- # clojure-greece (101)
- # clojure-poland (16)
- # clojure-russia (35)
- # clojure-spec (202)
- # clojure-uk (24)
- # clojurescript (69)
- # cursive (23)
- # datomic (34)
- # devcards (7)
- # dirac (5)
- # editors (3)
- # emacs (6)
- # events (1)
- # hoplon (52)
- # instaparse (1)
- # jobs (4)
- # jvm (2)
- # lein-figwheel (2)
- # leiningen (10)
- # luminus (2)
- # mount (1)
- # off-topic (12)
- # om (55)
- # om-next (8)
- # onyx (19)
- # pedestal (4)
- # planck (1)
- # re-frame (27)
- # reagent (5)
- # remote-jobs (1)
- # spirituality-ethics (14)
- # tmp-json-parsing (6)
- # untangled (121)
- # yada (32)
so I got the point where I think I am not using yada in the right way...I am basically wrapping my computations so that it does not throw because I want to have control over the returned payload in case of exception..but...I feel I can ask yada to customize this...for instance, I do:
(instance? PSQLException res) {:status 400
:message (str/trim (first (or (re-find #"Detail:(.*)" (.getMessage res))
(re-find #"ERROR:(.*)" (.getMessage res)))))
:error {:code -32603}}
in a normalize
function inside the :response
callback...maybe there is a way to just say to yada
: "hey, when there is an exception, can you please pass by this normalize
function?this way I don't need to use try
...`catch`
(btw up there is JSON-RPC 2.0)
@richiardiandrea You are using an 'escape hatch' which is ok. You are determining the status code is 400 is there is a PSQLException. That is not something that yada can figure out by itself. You should catch Exceptions that you can handle. If you let them through yada will see uncaught exceptions as 500. If you are sure 400 is the appropriate code in your case, you're doing this right. I would normally question whether all PSQLExceptions are the client's fault, but it's your app.
@tangrammer: logging the response body is possible if you make it a string or byte-array. But if it's a stream or nio channel you can't.
@malcolmsparks: at last i used this approach for logging middleware
(defn log-handler [ctx]
(if (>= (-> ctx :response :status) 400)
(let [body (bs/to-string (-> ctx :response :body ))]
(log/info "CALL >> " (:response ctx) " :: " (-> ctx :request :uri) " :::: " (-> ctx :parameters) " :: " body)
(assoc-in ctx [:response :body] (bs/convert body java.nio.ByteBuffer)))
(log/info "CALL >> " (:response ctx) " :: " (-> ctx :request :uri) " :::: " (-> ctx :parameters))))
resource=> {...
:logger log-handler
...}
so, only if i got >= 400 status code then i convert the body to string but i create a new buffer based on this string and attach it to the ctx@tangrammer: looks good to me
馃檪 it's a naive approach due that it doesn't consider special body types but is a starting point
You have to be careful logging large bodies. If you have a slow consumer, parts of the body could be sent at different times. When exactly should you log? At the start? At the end? I think the only compromise is to log metadata but not the body itself, unless it's a string. Coercing a body to a string could be very expensive. Try doing that with a video file boxset of Game of Thrones....
Yes. It's a great excuse for yada 2.0 ;)
But I'm holding off until Clojure 1.9 is out because yada is a heavy user of schema and spec needs the coercers (conformers)
I think they are conformers, but yes it's early days - I don't want to be an early adopter!
RE conformers, Alex M(iller has been cautioning against them. They are fairly simple to add onto spec though, there is a gist demo'ing a working implementation.
@dominicm: what was his reasoning against conformers ?
@mccraigmccraig: Perhaps I am misremembering, I can't find the comment now. But I did dig up the code in my process https://gist.github.com/gtrak/9b6d16d0423b284292dbbdd095bf91e9
clojure.spec can do runtime validation, but in my opinion, it's not well catered for.
@imre The case for spec is strongly towards function specifications during development only
There is a comment by Rich that you can use valid?
to do it explicitly, but in my opinion, it's design doesn't suit that particularly well.
runtime validation and detailed validation failure reporting are needed in a lot of business cases, if I cannot use spec properly for that, why should I double the dev and maintenance effort and write the same thing in spec and schema for example?
@imre: I agree. I've been working on a library in this space, and been thinking about it in general, for some time. Spec isn't general enough for me, I think this comes about from it's insistence on encouraging some use-cases of spec to be done in a more "clojure-y" way.
I agree with the points here. Lisp loves runtime. Everything else is catering to other languages' weaknesses.