Clojurians Log v2

A third option - I prefer to avoid any one such approach and instead do what makes sense at a particular location. Shoehorning a particular dogmatic approach can easily result in some gnarly code.

But using a specific approach does help when you're doing it within the scope of a particular API. It could even be an internal one, even a particular namespace.

+1 from me for "extremely depends on context"

Thanks yes. I'm asking specifically about application boundaries because I also don't want to add typing everywhere and lose flexibility because of it

I guess my question is, why are you wrapping a particular response at all?

> application boundaries There are two boundaries in applications - between an application an its users (whatever "user" might mean), and in the reverse direction, between an application and what it uses. Your code sample suggests that it's the latter. And that's exactly where I'd judge based on the context. If it's the former, then it's a bit surprising that something else straight up calls functions from your app. But there a uniform error interface makes sense. Personally, I'd return a map with a status field or something like that. See also: https://github.com/cognitect-labs/anomalies.

I guess my question is, why are you wrapping a particular response at all?so that I can move implementation details of when things are right/wrong down a level, for example instead of

(cond
  (f1 a) (report-error a)
  (f2 b) (report-error b)
  (f3 c) (report-error c)
  :else 
  (println "all good!"))

(let [results (do-api-calls ..)]
  (when (some has-error? results)
    (report-errors results))
  results)

In a lot of places like this, an exception would suffice. Then all that code becomes just (do-api-calls ...). In some cases, you can't just have the upstream deal with any possible exception - then (try ... (catch ...)) with wrapping the original exception could work. Or yes, returning some value that signifies an error. I haven't actually measured anything like it, but my intuition tells me that around 90% of all failures are or should be handled by logging the underlying cause and aborting or retrying the upstream workflow, whatever it is. So suppose you have a web server with a public HTTP API. You don't want to report all SQL errors and NPEs there, you just want to return HTTP 500 in case something is wrong because of the server and it can't be alleviated by the user. So naturally you have a middleware that catches everything that hasn't been yet caught, you log the exception, and you return an opaque HTTP 500 - no custom error handling at all, unless at specific locations where you can handle some specific error. Like e.g. turning FileNotFoundException into HTTP 404 or something like that.

> my intuition tells me that around 90% of all failures are or should be handled by logging the underlying cause and aborting or retrying the upstream workflow Thanks that makes sense, it reminds me of https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/#when-should-you-use-result

@c.els sorry I was unclear — I know the general approach (I call them https://www.daveliepmann.com/articles/idiomatic-clojure-errors.html), and was trying to drill into the dimension of "what about a particular situation calls for error maps instead of throwing an exception?"

very interesting write-up @daveliepmann thank you for for all the resources too! 📚 🧑‍🎓

*destructuring The error should still have a stacktrace somewhere. But it's probably about time_zone being nil. Why do you destructure like :user/keys? What does users/fetch-user-by-id return exactly? How are you making sure that the code does not run on startup? Regarding the last code block - is this the only change you have made to make the error go away?

Thanks, I was looking for the right word I was investigating an error about time_zone being nil. I discovered that in transaction contexts in my code because of the way I setup the database connection, data comes in fully qualified (:user/id, :user/time_zone, etc). Note that trying to do (:user/time_zone) failed the same way. I have logs that log out that area of the code with a debug to see if the time zone is null and they did not log out. The code is part of an endpoint, which isn't getting hit. This code doesn't run when I just deconstruct using :keys Yes, that is the only change I made to make the server run (but it is wrong as there's no data at that key)

I would try getting the full stack trace of that exception.

What type is returned by the function call?

(s/def :user/row (s/keys :req-un [:user/id
                                  :user/email
                                  :user/full_name
                                  :user/phone
                                  :user/calendar_source
                                  :user/surge_contact_id
                                  :user/time_zone]
                         :opt-un [:user/created_at]))

If it is a weird java.util.Map impl, but my guess would be something downstream that is depending on the value of time_zone, and the full stacktrace would point you to where

I would also dig into "runs fine, but is wrong"

I'm curious about why I get this error just running lein run

Given that this functino is part of an HTTP endpoint that wasn't cURL'd

Look at the whole stacktrace

It will tell you exactly what caused it to happen

Without looking at the stacktrace you are just kind of guessing because you can change a line of code and that changes the behavior, that code must be responsible for the behavior, but that is correlation, a stacktrace is causation

Ohhh I figured it out. there's an old piece of code that runs that on startup, and the namespace is unqualified in that run.

This is arbitrary - no police will show up on your door if you print from filter :^)

it's all fun and games until the referential transparency police show up at your door 🚓

Right!

maybe it's just different words because of the different authors, you could take a look at the source to see if it's relevant 🤷 https://github.com/clojure/clojure/commit/4ddc34ee11563345ad2142763c03495bf85110ff#diff-313df99869bda118262a387b322021d2cd9bea959fad3890cb78c6c37b448299R2808

yeah, I checked the original commit (https://github.com/clojure/clojure/commit/9b78d483959e912a2ef77ff649b893b035144549) as I thought maybe this has something to do with the transducer arities.

map on the other hand makes no such statements

swap!, which can call f arbitrary number of times, only specifies "f ... should be free of side effects"

clojuredocs contains a comment > Although the documentation states that the predicate must be free of side effects, it would be more accurate to say that you should not rely on filter to induce side effects that may be caused by the predicate, nor on the timing of when the predicate will be evaluated, because of the lazy and chunked nature of filter. which makes sense, but is there something else behind the choice of "must" vs "should"?