Fork me on GitHub

When throwing ExceptionInfos from different parts of the application (with a :type key in ex-data), and you want to handle only specific types, is it customary to just catch ExceptionInfo, check the :type in ex-data and re-throw if unrecognized?


or just use that does that and more 🙂


but yeah it's common.


On a related note, I improved quite a bit on that concept on another lib at work, it's on clojars already, just not open-sourced on gh yet (it will be very soon I expect)


it's heavily inspired by mpenet/ex


@dmarjenburgh There's also which allows you to just catch the ExInfo subclasses you're interested in


but I'm not sure if that works well, since I've never used it


for me, the obvious/oldest one is slingshot. I'm not sure how these compare.


and one caveat with the mentioned lib is that you would still have to check and rethrow in CLJS


defexception doesn't allow to express hierarchies. imho it's not so useful in practice

Alex Miller (Clojure team)13:10:05

I've used slingshot in anger and thought it was pretty good for this.


Out of curiosity, has anyone tried using derive applied to a type key and gotten a desirable outcome from doing so?


the lib I mentioned does that with an internal hierarchy. It's quite handy to express various things for exceptions "types" matching isa?, like controlling how to react on them


similar use cases to exceptions hierarchies in java


thanks, I’ll have a look


hey people, I even don't know how to ask it... but I am having weird clojure behaviour when I try to run 2 crux nodes at the same time -> crux internally relies on some clojure and obviously is compiling stuff... and what happens is that clojure randomly breaks on random errors like can't find wars, syntax errors etc... and it does not happen when there is only one instance of crux being build... Only thing is happening is that two instances created in same VM... Is there something in clojure which might cause something along those lines?


Are you trying to load different versions? Clojure doesn't play well with that.


@olekss.janis That issue seems very specific to crux, you might get faster and better feedback if you post this in the #crux channel. I'm curious to know what's happening as well


A long, long shot: Anyone seen a Transit implementation in C++?


A native C implementation of transit would be nice

Alex Miller (Clojure team)14:10:32

those are the ones I'm aware of, don't know of C or C++

Alex Miller (Clojure team)14:10:43

there are some edn impls in both - might have some small overlap that would be useful if starting such a thing


what’s the proper way to define a custom printer for a type?


I’m used to CLJS’ IPrintWithWriter, I don’t see the same for Clojure


I believe you need to extend the print-method multimethod


I recently saw this talk from Alex Miller on Spec:;t=1005s


.. I noticed that he's referencing a non-alpha version of spec possibly? Just wondering if this is close to release. I'd like to use spec but I'm still shy to use it due to the alpha badge and notice in the readme about it being subject to breaking changes. Are many people using it in production here and feel confident it's API won't break when it goes out of alpha?


@thiru0130 i have spec1 alpha code in prod and while it was useful and caught a few times where my app was being sent junk data, i wish I waited longer for things to settle down. i think generally there's no guidelines as to when spec will make it out of alpha

🙏 4
Alex Miller (Clojure team)17:10:29

that talk (which I don't even remember where it's from) is actually a couple years old and references namespaces from before we decided to make it alpha

Alex Miller (Clojure team)17:10:48

yeah, that looks like maybe a bootleg rip of my talk at Philly ETE in 2017, which is officially hosted at

Alex Miller (Clojure team)17:10:15

we are currently working on spec 2 ( which I am hopeful will become a non-alpha release version at some point in the next 3-6 months

Alex Miller (Clojure team)17:10:17

there are already, and will be more, breaking changes in the spec forms (most of the api changes are additive, not breaking), but this will all be happening in different namespaces than the original spec. Some transition will be required, but we hope to make it feasible to keep old things working (to some degree) while you move.


Should I wait for spec 2 if I don't know much about spec 1? 😄

Alex Miller (Clojure team)18:10:35

depends on your goals. If you're just looking to learn more, no reason to wait. If you're looking to make significant use on a project, you can safely use spec 1 for now and then switch, if your project scenario is tolerant of such a thing.


Awesome, looking forward to it! Thanks @alexmiller


Is there an index of links to clojure diagrams somewhere (e.g. The prepl one)

Alex Miller (Clojure team)23:10:22

I would actually hesitate to try to create such a thing because it implies a static-ness that is generally not accurate. the prepl architecture diagram currently available is at least the 3rd or 4th version. I'm sure it's not the last. Rich keeps omnigraffles with often dozens of historical versions over time. I have at least a half dozen variants of the spec 2 architecture lying around, some that represent intermediate steps that were explored only through pictures and never actually implemented.


I was going to put it together, but I'd like to convince you first so I'm not potentially upsetting you. I'm not interested in the diagrams from the perspective of implementation. I'm interested in them from the perspective of learning the process in order to use the same kind of process in my own work.

Alex Miller (Clojure team)17:10:52

well the "process" part of it is seeing N versions of the same diagram

Alex Miller (Clojure team)17:10:41

sounds like you want to grab frames from 10 movies and talk about movie-making

Alex Miller (Clojure team)17:10:08

I don't really want to add anything like that to the clojure web site right now as I think Rich would probably have mixed feelings about such a thing


I was interested in seeing examples of the elements stu talked about in his design after agile talk. E.g. the mixing of "types" of diagram together. The design process will reflect in the diagrams, but the expression of information can be captured in a single diagram, or am I missing the point?

Alex Miller (Clojure team)17:10:54

I haven't actually seen that one, so not sure

Alex Miller (Clojure team)17:10:39

maybe I should just roll back to what are you proposing to do?


Well I was wanting to study them for myself. But linking to them in a gist or something for others seemed like a friendly thing to do. I wouldn't want the existence of such a list to inconvenience anyone or poorly represent their ideas either (and that also applies to making sure I learn the right thing from them).

Alex Miller (Clojure team)17:10:24

seems fine, as long as you contextualize them


Speaking of which, do you have your slides online in pdf form or something so I can get the images of the diagrams (or perhaps sources for them)? The video is OK if they're not already up.

Alex Miller (Clojure team)20:10:25

I'd really prefer you don't use most of the ones in there as they were pulled from various places and are probably not the best versions of any of them (except the prepl one which is at


The deps one looked to match the one on The only novel one was the transducers one.

Alex Miller (Clojure team)21:10:05

yeah, I found that buried in my files, I don't know enough context to vouch for it

Alex Miller (Clojure team)21:10:19

the deps one is on the site so that's fine

Alex Miller (Clojure team)21:10:43

the spec 2 one was only a few hrs old and has already changed since


seeing the evolution is part of the value I think


Is there a core function that does something like this?

(defn index-by
  [f coll]
  (into {}
        (map (fn [elem]
               [(f elem) elem]))


I seem to do the above a lot. It feels like there may be a core function somewhere that does that already.


Kinda. Puts elements into a coll though.


Most of my cases are always cardinality one.


(juxt f identity)


(Appropriate use of juxt :)


That one is fun 🙂


index-by functions need to throw when there are dup keys, imho


Yeah, that's probably right.


Also be aware if f makes some of the elements collapse


Ah. What he said but ghadi said it better


(defn index-by
  "Builds a map whose entries are the result of applying
   keyf and valf to every item in the provided collection.
   Throws an exception if two items map to the same key,
   unless mergef is provided.

   valf defaults to identity"
  ([keyf coll]
   (index-by keyf identity coll))
  ([keyf valf coll]
   (reduce (fn [m v]
             (let [k (keyf v)]
               (if (find m k)
                 (throw (ex-info "Duplicate key" {:k k}))
                 (assoc m k (valf v)))))
  ([keyf valf mergef coll]
   (reduce (fn [m v]
             (let [k (keyf v)]
               (if-let [entry (find m k)]
                 (assoc m k (mergef (val entry) (valf v)))
                 (assoc m k (valf v)))))


My variant ^