This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # announcements (1)
- # aws (2)
- # babashka (15)
- # beginners (122)
- # boot-dev (1)
- # cider (3)
- # clara (7)
- # cljdoc (11)
- # clojure (161)
- # clojure-dev (45)
- # clojure-europe (8)
- # clojure-france (1)
- # clojure-india (1)
- # clojure-italy (3)
- # clojure-nl (11)
- # clojure-uk (34)
- # clojurebridge (2)
- # clojurescript (13)
- # cryogen (10)
- # cursive (13)
- # datomic (25)
- # emacs (8)
- # fulcro (76)
- # graalvm (2)
- # jackdaw (5)
- # jobs-discuss (2)
- # juxt (13)
- # off-topic (13)
- # pathom (5)
- # pedestal (7)
- # quil (2)
- # reitit (9)
- # remote-jobs (4)
- # schema (1)
- # shadow-cljs (33)
- # spacemacs (8)
- # sql (9)
- # vim (2)
- # vrac (2)
I remember a while ago seeing a wiki page which had a list of the different categories of error messages, and comparisons of how they are handled in Clojure 1.10+ and in previous versions. I can’t find it now, can anyone help me out with a link?
The main design page was https://archive.clojure.org/design-wiki/display/design/Error%2BHandling.html
and this links to a redirect page that has a bunch of links to subsections of that https://clojure.atlassian.net/browse/CLJ-2373 (but it seems the nav is broken)
Actually, this was the page I was after, I found it via @seancorfield’s link: https://archive.clojure.org/design-wiki/display/design/Exception%2Bhandling%2Bupdate.html
Is it the intention that the data from
Throwable->map be readable? Currently for a spec error they’re not, because the spec itself is printed as
Regarding the readability issue, that is a known issue, should really be the s/form
Thanks. I’ll transform the errors before I send them back, then. I guess when I receive them I’ll have to transform them back so that ex-triage works correctly?
Actually, that doesn’t seem necessary - just transforming on the sending side seems to work fine.
Can a type or record in clojure be extended to behave like a function and multimethod? This is easy w/ clojurescript but I'm stuck trying to get this to work in clojure. I'd appreciate any way to make this work since it breaks CLJC compatibility and with that the API of a library I'm planning to open source soon. CLJS example:
(defrecord MyMulti [add-method remove-method dispatch-fn method-table] IMultiFn (-add-method [_ dispatch-val f] (add-method dispatch-val f)) (-remove-method [_ dispatch-val] (remove-method dispatch-val)) (-methods [_] @method-table))
@bronsa to provide some more detail: I'm looking to be able to use
defmethod in cljc on my own type/record that exposes similar behavior.
Sorry about raising a topic again but I wonder why
(get 1 1) ;;=> nil? 🙂 found that from the very beginning https://github.com/clojure/clojure/commit/1c9de854a30e116e502c2d0bebaadce8f80219fb
this is widely known, and has been discussed to the point that it brings on a deep feeling of weariness to see it brough up again
but I suspect the discussions might be deep in the depths of the google group, searching of which is a pain, so you might want to throw it on http://ask.clojure.org to get an easier to find discussion
> searching of which is a pain @hiredman exactly, sorry for annoying raising it up again, I should have asked “where was the discussion”, this is really un-googlable unlike say https://stackoverflow.com/questions/28934385/why-does-count-nil-return-0 but anyway “spec says so” (here: “nil if key not present”) doesn’t answer why 🙂 could you share the essense idea of that google group thread?
I don't recall, and I don't think it was once, I just think it has come up a number of times, and my (entirely unfair and overly general) summary is: rich likes it that way
in some cases there’s a sort of “nice” flexibility in being able to do
(get x "blah") on anything for
I think, and I don't recall the argument being put in these terms, the rational is something like "it is nice for get to be a total function"
There is a jira to throw on non-associative args to get, which has been debated off and on
Is someone out there relying on this such that they would be broken if it changed? No idea
Given how prevalent
get probably is in Clojure code, it seems fairly likely someone is relying upon it. There has been 12 years and tens of thousands of developers for Hyrum's law to be enacted there.
I was browsing through http://ClojureDocs.org page for
get to see if it mentioned any motivating reasons, but no. I did find this behavior that I probably actually documented, but had forgotten, which only happens for vectors, arrays, and strings, I believe (occurs because of truncating behavior of a call to intValue in the implementation):
user=> (get ["a" "b" "c"] 4294967296) "a"
(get ["a"] (* 2 (inc Integer/MAX_VALUE))) (.intValue (* 2 (inc Integer/MAX_VALUE))) ;;=> 0