Hi. Great! However, it's better not to cross-post across multiple channels. Specifically for release announcements we have the #C06MAR553 channel.

thanks @U2FRKM4TW 🌹

It's really contextual, but I usually write variant 1 in handler-y type functions (because of logging), and variant 2 in more business logic (when I only need the final outcome to tell me what happened)

This gets asked once every few months, so it should be possible to find previous discussions here. I myself prefer either the initial or the 2nd approach. I try to avoid the 1st one if the validation is a part of the business logic and not a safeguard against dev mistakes. Some people prefer error monads. I think there's one or two libraries for them.

I've used delay with version 1. in the past (but without exceptions) for that specific problem. And then just cond to have everything "flat". I feel like it keeps the code readable.

https://github.com/fmnoise/flow can be considered a hybrid solution as it uses exceptions, but then usage looks sort of monadic (as in sweet/streamlined) Personally I tend to be attracted to the Result pattern ("error monad") as it fits particularly well in codebases that annotate functions with Spec or Malli. It's fairly simple. You cannot really "spec" exceptions (that is, with a commonly understood type/spec system).

Here I might use a lightweight error-monad-ish pattern, like

(ok-> {}
      (expensively-assoc-code)
      (expensively-assoc-email))

we don't use this pattern everywhere, but at my job we have a with-validation macro in our route handlers, used like (with-validation obj [fn1 fn2 fn3] sym ...body) that expands to (roughly)

`(loop [results# {}
        [next-validator# & remaining#] ~validators]
   (cond
     (contains? results# ::errors) (error-response 400 (::errors results#))
     next-validator# (recur (merge results# (next-validator# ~obj results#)) remaining#)
     :else (let [~sym results#] ~@body)))

i think this is how a lot of flow works, but i'd have to look at it again

could this be a good use case for core.async ? I could dispatch every expensive op "at the same time" and collect each result from a channel, when the first :error is read then, close the channel and return

That would work only if you're fine with doing extra work and the functions can be run independently of each other. And the approach doesn't require core.async at all - it's just a collection of futures. If any of the tasks is CPU-intensive, core.async is an even worse fit.

what about failjure?

@U05092LD5 When I read about railroad-oriented programming, I made a tiny experimental library that generalised the ok-> pattern you write about. I'm not entirely happy about it - the generalisation I came up with causes exceptional-looking threading - but it was fun to try it out. What do you think? https://github.com/Reefersleep/thread-until

@U0AQ3HP9U Cool! I'm still using https://gist.github.com/daveliepmann/fc2d9f93d51e6bdba0e7e28b1a2a6b26 A former colleague of mine had a similar critique, that the errors still need to be "caught" like exceptions. That's valid. Would love to hear more about your experience and feelings about "exceptional-looking". I think this approach really shines in situations where there are a large number of business objects to be processed, there are multiple distinct ways for each one to fail, and you don't want to stop the whole pipeline on any single failure.

@U05092LD5 imo the "catching" of `:error isn't an issue :) At least it's easy to standardise on a recognisable pattern when using these macros. Your collection of macros seems fine to me. Sounds like you've made more use of them than I have of mine - I actually didn't find any good use cases in my code base at the time and kind of left the library as is. What I meant by "exceptional-looking" was that I have a mandatory two first items in my threadings, and it doesn't look good, whitespace-wise, when either the predicate fn or the data literal (or both) are too big (and that's a very small limit - as soon as they're more than 1 line, it looks off). I really don't like this, and it's actually what's put me off of looking for good use cases for my macros. (And then, I just forgot after a while)

Is this name special somehow? This also happens for test/foo/test_helper.clj.

Not special in any way. Is test on the classpath?

you can just http://java.net.http.HttpClient without a wrapper

we’re using https://github.com/babashka/http-client

oh i like this -- i had no idea the bb library worked on clj too

but @U0NCTKEV8 you're right... i still always get a little stressed when i call JVM things directly. i gotta get over it

if you're used to clj-http, then hato is a good replacement -whether you like working with the interop or not

babashka.http started out as a fork of https://github.com/schmee/java-http-clj which is another option

I would still avoid hato because of this issue https://github.com/gnarroway/hato/issues/43

i know if i want it fixed i should PR, but i haven't had time or focus

Mostly using aleph