> which is more idiomatic? Neither. There are as many opinions on specifics as there are people here, it seems. Personally, I don't have a principle, nor do I have a decision tree to choose which approach I want to go with. Rather, I go by intuition. Way too many variables for me to come up with an unambiguous and satisfactory decision tree.

It has been discussed a lot, there is a long thread: https://clojurians.slack.com/archives/C03S1KBA2/p1685602577100679

Generally I don’t think generic utilities and “library code” should throw exceptions, but instead either do nil-punning where suitable, or return more rich descriptions of errors/problems. However, I do find careful use of exceptions in high-level business processes acceptable - especially when using ex-info to carry data with the exception. I tried pretty much all the alternatives here a few years ago, and was originally very anti-exceptions and pro custom data for communicating errors. This led me to try libraries like https://github.com/adambard/failjure and others like it. Eventually though, it occurred to me that I had really just replaced the try/catch built-ins with an extra third party dependency and custom-made macros that did basically the very same thing. So I reverted out of the experiment and found piece with careful use of exceptions in high-level code where I do not want the code to continue running past an error.

yeah, just saw the thread by Paavo, going through it 🙂

As a side-note I try to steer away from any pattern that makes my application dependent on third-party libraries for basic control-flow and core concepts. I don’t want a single library to permeate my entire code-base. It raises the bar of entry for other developers, makes you overly reliant on one dependency, and steers you away from simple clojure.core-based solutions.

yep, agreed on that one; not just for exceptions but for almost anything really - the closer to clojure core your code is the easier to understand is by everyone

I like exceptions, and I do indeed come from the java world. that being said, I’ve seen them used and abused in many, many cases I wouldn’t personally call ‘exceptional’ 🙂

@U053URTDGDD - what would you consider exceptional? http 404? 403? 429? unable to establish db connection at application startup? unable to establish db connection for a specific user request? malformed sql query? division by zero?

I tend to: • default to nil punning/err msg(or map) most times • bite the bullet and accept try/catch/throw if the codebase I'm changing is to difficult to adapt to a non-throw approach; • complain a lot and being the anti-throw advocate if the try/throw/catch web is just too messy 😄 thanks to nil punning and other sensible defaults in Clojure land (eg side effects mostly isolated at the edges of a system - such as api calls, db connections - almost only pure functions everywhere else) I have yet to see a Clojure codebase which is seriously compromised by try/catch pollution, that is more the case in Java/C#/JS land. I haven't tried a monadic approach yet (failjure, o even better, to try it in languages which embrace natively that approach) in a work environment so I can't express a preference here, but I'm definitely curious about it.

• http responses: ◦ am i handling them? if so, probably not. they’re so non-exceptional, it neatly fits into a sort of error map, maybe not unlike what you’d proposed - {:status 400} 🙂 OTOH, if my app can do nothing without a 2XX, then that may indeed be exceptional for my app ◦ am i sending them? if so, certainly not • unable to establish a db connection ◦ do i expect this situation and have a backfill/cache to use? if so, certainly not ◦ if not, and i’m dead in the water without that, probably exceptional ◦ for a specific user request: ▪︎ i would likely try to shy away from exceptions, especially if i’m trying to maintain a high throughput. those stack traces are expensive! in any case, i feel like most db libraries i’ve used treat this as exceptional anyway. do i re-throw? if there was a way i could afford not to so as to quickly retry the request, or signal to the consuming API that they should retry soon, i’d rather do that EDIT: i’ll leave it there for now so as not to clog the thread, but that’s some of my back-of-napkin line of thinking about this

> I’ve seen them used and abused in many, many cases I wouldn’t personally call ‘exceptional’ exceptions for control flow, I suppose 🙂

A good case for exceptions in clojure came up in my work yesterday. I have a function foo* that creates an object based on the input parameters. I also have a function foo which is just (memoize foo*). If (foo* :a) fails for some reason, I do not want it to return nil because I don't want (foo :a) to cache a nil. Rather, I want (foo* :a) to throw an exception so that nothing is cached for a memoized call.

My rule of thumb is that exceptions are broken assumptions. I don't like to throw them except I want the program (thread/process etc.) to actually crash. When throwing an exception I'm saying: "I can't do anything further here, but here's some information that might help to fix the problem." A caller should be able to choose whether, when and where they handle it. In the general case, I rather return a value that describes w/e the state is. In that case the 'error value' is part of normal control flow. I'm saying: "Here is some information about the program state."

I think there are some languages where you want to throw exceptions all the time, because your IDE jumps in there and lets you fix the state on the fly. There exceptions are part of interactive programming. But I don't think Clojure offers this.

I didn’t read all this text, but I would say: 1) remember catch doesn’t have to be (catch Exception ... to cach everything. You can use specific class to handle exception in right way. You really should. This already solve most of issues. 2) But on some level you catch all and you expect unexpected exceptions. This is fine. 3) Use cause instead of re-throw exception as it is. 4) add debug data with ex-info 5) in API which has clear response error to help developers understand what is wrong it is fine to throw exception and later on, on the top level check (= :validation (:type (ex-data error))) to identify exception as expected and convert error to human readable form informing about for example connection timeout to third party system or some not valid data deeper in the code. Why? Because otherwise each function in the flow has to know how to differ expected data vs error data. Exception cut the flow immediately and from deep deep fn you are immediately in the code which decide what to return in response in such case.

in elixir you don't have a choice, so error objects are a successful way of doing this, but in java/clojure you are going to end up in a mess of both types, at least at some level.

In clojure code, I nearly never invent/throw exceptions (with the exception of a math lib I wrote (pun intended) 😉). Even in Java I rather have the caller decide, if something is exceptional or not. For example in validation functions I return a collection of validation errors and the caller can decide to handle them in the normal flow of control or to throw an exception. On retrieving external state by some criteria (e.g.), I provide a 'find' and a 'get' method. In 'find' it's ok, if nothing is found and null/nil is a valid return value, in 'get' a result is expected and an exception is thrown, when the state is not there.

i avoid exceptions whenever possible (unless a library i use throws them and i have no control over that) especially because the significant performance penalty of building an exception. i was shocked how slow it is.

@U053URTDGDD - you say you like exceptions, but from your description it seems you use them quite sparingly... I don't like them, but at least superficially I use them in a similar way; for example I try to not use exceptions as a general rule, but as you say if I'm dead in the water and the alternative is to change every function along the chain to check for nil/error (during system startup for example) - I'd just throw an exception as well; http/db/etc requests and user requests are not exceptions, we should be expecting issues with connectivity/discoverability/etc; I guess the only difference is if my app can do nothing without a 2XX, then that may indeed be exceptional for my app - I'd try to return something more meaningful rather than throw

@U017QU43430 - I feel for you, I've ended up being the anti-throw advocate a few times 😅

@U0608BDQE - that's interesting; so you avoid memoization because if foo* gets retried it might succeed?

just to extend my previous answer: Personally I don’t have any issues with exceptions if these is done in the way how I described. But I have issues with exceptions because of team work. People do code in different quality and this also apply to exceptions mess. Usually developers don’t spend enough time to learn how to do this things in high quality for exceptions and logs. The topic itself is deeper, than it looks on first glance. Not investing time to learn how to log, throw and catch exceptions is the issue. Not exceptions itself. After all exceptions are not only to not crash app, but to alert developers and provide data to understand what happen. This is the most important thing.

So there are 2 types of exceptions: 1) expected exceptions - if input data is not valid or third party system fail because of network connection etc., then throw exception and return 0 or current time as default value 2) unexpected exceptions - alert developers and provide data to fix the issue For 1) we should also measure exceptions, because too many expected exceptions is unexpected and means not expected bug :)

@U0WL6FA77 - I'd argue that if you're expecting an exception it's not really an exception - it becomes an ordinary issue, not something "exceptional"; and most exceptions, even in OO land, are thrown in unexceptional situations

For example I expect exceptions for third party bookeeping and warehouse system, because often it has timeout. I want to log it, I want to measure it, but I expect this behaviour, so I don’t want to be alerted. This is not something possible to fix. It is something to live with.

but if it is happening too often, then it needs attention and became unexpected.

For example they changed API to add extra data in response which increase timeout from few % to 90% which made system not functional.

the same technical exception, but in different numbers made it unexpected

> I’d argue that if you’re expecting an exception it’s not really an exception It is still exception from technical point of view. But as a concept it is expected exception and from that moment you can code your system to handle that in expected way.

> code your system to handle that in expected way. this is the point for type 1)

replying to https://clojurians.slack.com/archives/C03S1KBA2/p1688971370565369?thread_ts=1688741187.820029&cid=C03S1KBA2 above - I like fire alarms, airbags, and parachutes, but I try to use them sparingly, as well 😉 (though I surely use exceptions a bit often than those…)

to extend what I mean for 1). In the moment of throwing exception you can’t determine if this is expected or unexpected. The conclusion is delayed until your aggregate data.

> I like fire alarms, airbags, and parachutes, but I try to use them sparingly very well put 👌

Kaocha has a cloverage extension: https://github.com/lambdaisland/kaocha-cloverage

I believe you can also use coverage directly with deps cli https://github.com/cloverage/cloverage#clojure-cli-tool (the dep should be coverage/coverage to avoid errors about unqualified libraries). I'd recommend creating an alias in deps.edn with the dependency and run config so you can run it with something like clj -M:coverage or similar

With kaocha: Adding in deps.edn

:kaocha  {:extra-deps {lambdaisland/kaocha {:mvn/version "1.1.89"}}
                     :main-opts  ["-m" "kaocha.runner"]}}}

#kaocha/v1
{:tests [{:id :unit
          :test-paths ["test"]
          :plugins [:kaocha.plugin/cloverage]}]} 

$ clojure -A:kaocha
Error building classpath. Could not find artifact lambdaisland:kaocha:jar:1.0.75 in central ()

I managed to work with Cloverage, thank you @U052PH695! I also want to achieve the same with Kaocha. I'll try to solve the issues by myself, but @U0JEFEZH6, if you have any tips on how to solve them, I would be grateful!

You can also use https://github.com/practicalli/clojure-cli-config as reference for all things tools.deps (yes, it has specific Cloverage coverage)

lol i know it's a simple two lines and i shouldn't bother, but going over the list twice makes my eye twitch, but using reduce or loop also makes my eye twitch given how much more code i'm adding

(apply map #(into #{} %&) '([1 2] [3 4] [5 6]))

Not comparing O(2*N) to 2*O(N) makes programming much more fun. :) I'd definitely go with the most explicit solution, regardless of the fact that it creates two lazy sequences.

(reduce (fn [sets [a b]]
          (-> sets
              (update 0 conj a)
              (update 1 conj b)))
        [#{} #{}]
        '([1 2] [3 4] [5 6]))

just to throw in another option, if you're prepared to use cgrand's xforms lib, you could reach for transjuxt (which is a tripple word score in clojure-scrabble)

(sequence (comp (let [xf #(comp (map %) (x/into #{}))]
                    (x/transjuxt [(xf first) (xf second)]))
                  (mapcat identity))
            [[1 2] [3 4] [5 6]])

How about apply map hash-set '([1 2] [3 4] [5 6]) so you don't need the anonymous function?

Indeed! Good catch.

Very neat, @U04RG9F8UJZ. Thanks everyone, I enjoyed this thread 🙂

@U0AQ3HP9U thanks. This is something I just learned recently through Advent of Code. In general, taking advantage of the fact that map accepts multiple collections and passing the nth element through to a varargs mapping function (i.e. apply map some-varargs-fn coll-of-colls) effectively let's you transpose the coll-of-colls. It was really neat to see that pattern. I did it with str as the mapping fn, but it fit so neatly here too to transpose a collection of entries to a collection of keyset valset.

@U04RG9F8UJZ it really is neat functionality of map that I also forget to use.

IMO the fact that many people forget that (apply map ...) is effectively transposing the data might indicate that it's not something that should be used. At least, when corroborated with actual measurements of frequencies in OSS code. Or it can signal the need for better documentation of that pattern. But I still can't fathom how it could even potentially be more graspable at a glance than the code in the OP. (Apart from that, the code works differently if there are items with less than 2 items - unclear whether it's important for the OP but definitely important in general.)

i tend to not like using the var-args version of map cuz it works so much differently than map functions do normally (in other languages). are there any other functions that work the same within clojure?

@U2FRKM4TW personally, I find it fairly intuitive :man-shrugging::skin-tone-2: I certainly won't argue more so than the original code snippet, but certainly more so (to me) than the other proposals in this thread. There's an example of transposing a collection of vectors as part of the first code sample on Clojure docs, so it's out there in docs at least. Really good point about the number of items: there's that extra constraint that all the inputs are indeed pairs (in this case). Irregularly sized collections would give incorrect results as data would be dropped

To be clear, I'm a Clojure newbie, so I don't really know how this compares to idioms in the wild. It seemed a likely one to me after reading the docs and reading about the cool pattern of into and mapping with juxt for transforming one map to another. I got the feeling that economy of code was useful in clearly communicating an idiom (not terse for the sake of terse, but economical such that there's less pieces to learn and understand to grok how it works) as it ends up easier to identify at a glance

On the subject of idioms, is there ever a situation where you'd apply map and are not mapping across a bunch of collections (e.g. transposing)? What I'm wondering is: is it safe to infer a particular meaning from seeing apply map (regardless how common it is to see), or is there more than one use case (and perhaps a more common one than this)?

Can't think of any since all arguments but the first are supposed to be collections. Except for toggling between the 1- (transducer) and 2-arities when given an empty collection or a size-1 collection. But that'd be bizarre.