Thanks Tom, addressing some of your points below:
- No criticism of the design choices, but the resolver functions in the
> tutorial are a bit busy at a glance, especially since they are responsible
> for the wrapping w/ mfd/future and d2q/result-cell. I suppose some helper
> functions/macros c
Why exceptions are the pattern we encourage? So if I spec'ed my function
input, output and input-to-output there is no way to specify errors when
something goes wrong, because neither spec nor clojure does not allow you
to describe exception that can be thrown in your function. Returning
"monad
Have anybody seen any perf improvements due to JDK8+ bytecode compatibility
which this release brings ?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are
I wouldn’t expect any. Would be interested to hear any perf differences you see
either way though.
> On Oct 26, 2018, at 4:27 AM, Piyush Katariya
> wrote:
>
> Have anybody seen any perf improvements due to JDK8+ bytecode compatibility
> which this release brings ?
> --
> You received this me
Because Clojure is on the JVM and interops with Java and exceptions are the
provided error handling mechanism.
Exceptions are not spec'ed because specs are designed to specify the
expected inputs and outputs of a function and exceptions are ... exceptions
to that. (Generally, I don't feel that
James,
Thanks for pointing out the submit function and explaining the wrapper.
Would you specifically advise against sending the result back through a
channel? I have made a prototype (using ExecutorService) where the email is
provided together with a channel and the sender starts a small go block
On Fri, 26 Oct 2018 at 14:05, wrote:
> Thanks for pointing out the submit function and explaining the wrapper.
> Would you specifically advise against sending the result back through a
> channel?
>
It depends what you're trying to do. What are you doing with the result,
and what's your reasoning
Expert answer is always “it depends”.
And long winded answer:
I’d first write a function that can send one “email”:
(defn send-email! [ctx email-data] …) ; context contains whatever outside
resources you need
Now you have the freedom to work on a list of email-data like this:
(doseq [email em
I don’t have any hard evidence about performance but when we first updated to
the 1.10 build that generated the new bytecode, it _felt_ faster – our test
suite seemed to run faster locally (so maybe the compiler got faster?). We have
not seen any measurable difference in production (but we’ve ha
For our REST APIs, we have middleware that catches exceptions, logs them, and
returns an error response to the caller.
If we have a specific handler that can fail in an expected way, we write that
into the logic and respond to the caller with an error response – much like the
middleware does.
Likely the biggest performance gain is that compatibility fixes allow you
to run up to Java 11, thus reaping any benefits from newer JVMs.
On Friday, October 26, 2018 at 11:09:39 AM UTC-5, Sean Corfield wrote:
>
> I don’t have any hard evidence about performance but when we first updated
> to th
Verification time should go down with JDK8 level bytecode, which improves
cold startup of clojure.jar by about 5%. (This benefit is negated by the
module system in 9+ though.)
On Friday, October 26, 2018 at 12:27:44 PM UTC-4, Alex Miller wrote:
> Likely the biggest performance gain is that comp
Sean, if you were to Spec your API responses, what would you do for your error
response?
This is my issue. I operate in a distributed environment. If I produce a set of
data, but one field failed to compute properly, maybe a downstream system was
down, maybe some information I was given to comp
I think it's perfectly fine in this case to model an error message. But
that's not something done anywhere in Clojure APIs and not at all
standardized. It definitely makes sense for you to make, but it does not
seem like a thing that should be in spec itself.
On Friday, October 26, 2018 at 1:35
I would likely only spec the status 200 OK responses. We use 400-series status
values when we send back an error. You might consider that to be the
“exception” of the HTTP world 😊
We actually do have a documented format for 400-series responses but pretty
much any part can be omitted so calle
I've got the idea that you're not going to including anything like this
into core library. I just want to clarify because I'm actually a bit
confused here, and I think I'm not the only one. We promote
doing functional programming, staying declarative when possible, using data
with small pure te
For any library – for any function – there are always two classes of unhappy
path:
1. Expected, known failure modes.
2. Unexpected, exceptional failure modes.
The former should not use exceptions. The library/function should signal the
error in a documented way through its return value.
Sean, that's what I'm actually talking about.
1. There's no standard way to return "predictably" bad result. I don't know
what you meant with "documented way through its return value". There's no
Either with Left/Right (Scala, Haskell), no Result with Ok/Error (Rust),
there's no "second value w
I found the `cognitect.anomalies` namespace useful to provide some
uniformity in error codes and their meaning.
https://github.com/cognitect-labs/anomalies
On Fri, Oct 26, 2018 at 6:03 PM Oleksii Kachaiev wrote:
> Sean, that's what I'm actually talking about.
>
> 1. There's no standard way to
1. There's no standard way to return "predictably" bad result.
Given that the examples you provided are from typed languages and Clojure isn’t
typed, what would satisfy you here? A “recommendation” from Cognitect that such
success+result/failure+error-info situations use certain specific keys
> I’m genuinely curious as to what you (and other folks) would like to see
> added to Clojure to satisfy this “need”.
I'm proposing we add a spec for it, which would conform to success or error.
This would still allow flexibility in that you can choose your own error
structure, and success stru
I'm proposing we add a spec for it, which would conform to success or error.
Something like this, perhaps?
user=> (s/def ::result (s/and (s/keys ::req [(or ::ok ::error)]) #(not (and
(contains? % ::ok) (contains? % ::error)
:user/result
user=> (s/valid? ::result {::ok 1})
true
user=>
No, I'm thinking more like:
(defmacro errorable
[success-spec error-spec]
`(s/or :success ~success-spec
:error ~error-spec))
(s/def ::result (errorable string? #{:authentication-failure :missing-input})
(s/conform ::result "Here is a successful and valid result.")
-> [:success "Her
23 matches
Mail list logo
