RE: An Error spec?

[Didier]

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 "Here is a successful and valid result."]

(s/conform ::result :missing-input)

-> [:error :missing-input]

Now we have a standard spec for something that is either in success or in 
error. And it conforms to standard representations, a vector pair, with first 
being either the :success keyword or the :error keyword.

You can add convenience function to this if you want, like:

(defmacro if-error
  [spec value do-when-success do-when-error]
  ...)

(if-error ::result result
  (display result)
  (display "An error occurred, please try again.")

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: An Error spec?

[Sean Corfield]

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=> (s/valid? ::result {::error "bad!"})

true

user=> (s/valid? ::result {::error "bad!" ::ok "wat?"})

false



And, presumably, some helper functions to construct an “ok” or “error” result, 
and maybe ask if a result is “ok?” or “error?”, and maybe some convenient 
accessors? Or just ::ok and ::error directly?



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Didier 

Sent: Friday, October 26, 2018 8:45:23 PM
To: Clojure
Subject: RE: An Error spec?

> 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 structure. But it would also add a convention to at 
least formally specify predictable errors.

You can then know if what you got is an error or not by conforming it against 
the spec.

And you can tell if something can return predictable errors, as well as success 
values and exceptions by seeing that the return is of the errorable spec (or 
some other name we can come up with).

Personally I feel this would be good enough, and it seems to respect the 
general Clojure mindset of dynamism and flexibility and not making concrete 
choices for you. And I'd be happy with that.

You could, though that's not something I care for, go further and provide a 
standard error record in core, or a standard error protocol. That said, I feel 
that would maybe be a bit too far, especially, it feels like it might go a 
little against the spirit of Clojure till now. Since I know of no standard 
records, and very little standard protocols.

--
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: An Error spec?

[Didier]

> 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 structure. But it would also add a convention to at 
least formally specify predictable errors.

You can then know if what you got is an error or not by conforming it against 
the spec.

And you can tell if something can return predictable errors, as well as success 
values and exceptions by seeing that the return is of the errorable spec (or 
some other name we can come up with).

Personally I feel this would be good enough, and it seems to respect the 
general Clojure mindset of dynamism and flexibility and not making concrete 
choices for you. And I'd be happy with that.

You could, though that's not something I care for, go further and provide a 
standard error record in core, or a standard error protocol. That said, I feel 
that would maybe be a bit too far, especially, it feels like it might go a 
little against the spirit of Clojure till now. Since I know of no standard 
records, and very little standard protocols.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: An Error spec?

[Sean Corfield]

  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 in a 
hash map for the overall return value? A new clojure. that includes 
a spec for such a map and helpers for the ok/error cases?

I’m genuinely curious as to what you (and other folks) would like to see added 
to Clojure to satisfy this “need”.


  1.  The standard library throws exceptions even when the error might be 
conveyed as the result of the call.

First off, a nitpick: Clojure doesn’t have a standard library. There’s “the 
namespaces that ship in the org.clojure/clojure dependency” and then there’s 
“the various Contrib libraries”. The Clojure/core folks control the former but 
could only make recommendations regarding the latter (although, if a core 
change added a “standard” way to report s+r/f+e-i, then maybe Contrib authors 
would migrate to that – but see caveat below).

Second, as I indicated in my previous response, I think that code that throws 
exceptions for a perfectly predictable error situation is wrong – in most 
cases. Clojure.core/read is an interesting example because, by default, if it 
hits EOF, it throws an exception but it allows you to override that behavior 
and, instead, return a value at end of file. Normally, I’d say that default 
behavior is wrong: EOF is a predictable failure mode – but this is a case where 
it is most convenient to have read return the value that is read and there is 
no universal value it can return to indicate EOF since it can read and return 
any valid Clojure value (including nil or any namespace-qualified 
keyword/symbol etc). This is a case where the simplest possible API is to have 
read always return (just) the value it read on the happy path but to throw an 
exception if EOF is encountered during reading. It’s simpler because Clojure is 
a dynamic language without types like Either, Result, etc. Your choices are 
either force all users of read to deal with s+r/f+e-I map values and decoding 
or to force all uses of read to deal with exceptions.

I’m curious as to what you’d have clojure.core/read do here? (and feel free to 
point me at other Clojure functions that throw exceptions where you think 
returning s+r/f+e-i would be “better” – happy to look at several different 
cases!)

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Oleksii 
Kachaiev 
Sent: Friday, October 26, 2018 3:02:54 PM
To: Clojure
Subject: Re: An Error spec?

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 with an error" (Go) etc etc etc. You have to come up 
with your own way to distinguish bad and good result. And they will be 
different for different libraries. And that's right the problem I've stated in 
my message. No unification means manually work in each use case.

2. The standard library throws exceptions even when the error might be conveyed 
as the result of the call. Probably because of #1 - there's no way to express 
that.. Well... except exceptions. So, we're running circles here.

BR,

On Saturday, October 27, 2018 at 12:48:27 AM UTC+3, Sean Corfield wrote:
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. Calling code should check 
the return value to see if the library/function failed in one of the expected, 
known, documented ways it is known to be possible to fail in, and respond 
accordingly.

The latter can (and should) use exceptions. An exception says “I got into a 
state I can’t handle because I wasn’t expecting to get there!” and maybe the 
caller can handle that and maybe it can’t. Library/function authors can help 
callers here by:


  1.  Providing a clear but succinct message for the exception,
  2.  And providing as much potentially useful detail in the ex-data as 
possible.

Does Java (and its standard library) overuse exceptions? Yes, absolutely. It 
throws exceptions for all sorts of completely predictable failure modes. We 
don’t need (or want) to be Java.

Clojure provides perfectly good features to support both the expected and the 
unexpected failure modes and, in particular, provides an excellent way to 
convey information about the point of failure 

Re: An Error spec?

[Benoît Fleury]

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 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 with an error" (Go) etc etc etc. You have to come
> up with your own way to distinguish bad and good result. And they will be
> different for different libraries. And that's right the problem I've stated
> in my message. No unification means manually work in each use case.
>
> 2. The standard library throws exceptions even when the error might be
> conveyed as the result of the call. Probably because of #1 - there's no way
> to express that.. Well... except exceptions. So, we're running circles here.
>
> BR,
>
> On Saturday, October 27, 2018 at 12:48:27 AM UTC+3, Sean Corfield wrote:
>>
>> 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. Calling code should
>> check the return value to see if the library/function failed in one of the
>> expected, known, documented ways it is known to be possible to fail in, and
>> respond accordingly.
>>
>>
>>
>> The latter can (and should) use exceptions. An exception says “I got into
>> a state I can’t handle because I wasn’t expecting to get there!” and maybe
>> the caller can handle that and maybe it can’t. Library/function authors can
>> help callers here by:
>>
>>
>>
>>1. Providing a clear but succinct message for the exception,
>>2. And providing as much potentially useful detail in the ex-data as
>>possible.
>>
>>
>>
>> Does Java (and its standard library) overuse exceptions? Yes, absolutely.
>> It throws exceptions for all sorts of completely predictable failure modes.
>> We don’t need (or want) to be Java.
>>
>>
>>
>> Clojure provides perfectly good features to support both the expected and
>> the unexpected failure modes and, in particular, provides an excellent way
>> to convey information about the point of failure even when our code doesn’t
>> know how to recover.
>>
>>
>>
>> As Alex says, there may be value in providing a spec in your library for
>> the sort of ex-data you provide around exceptions. You’ll already be in
>> “regular Clojure land” as far as functions that return values that may
>> indicate success or expected, known failure modes.
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>> --
>> *From:* clo...@googlegroups.com  on behalf of
>> Oleksii Kachaiev 
>> *Sent:* Friday, October 26, 2018 2:28:35 PM
>> *To:* Clojure
>> *Subject:* Re: An Error spec?
>>
>> 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 testable functions as much as we can... and at the same
>> time declaring the "official" way of handling errors using exceptions,
>> which are side-effects by their nature, even tho' they play really poorly
>> with:
>>
>> * laziness (which is a default behavior for most operations with most
>> collections in the language)
>>
>> * multi-threaded code (especially in case of "opaque" jumps between
>> threads/executors when using core language concurrency primitives, or even
>> trying to emulate async event loop, i.e. with core.async)
>>
>> * macros (often macroexpand screws up the only feature we love about
>> exceptions: traces, making them pretty much useless)
>>
>> I thought that the design approach of using data and staying declarative
>> should also be applied to errors handling. And a contract declared for a
>> function should reflect not only "the happy path" but all potential cases.
>> We see a lot of languages put some mechanics into the core library or
>> language design (i.e. Scala, Rust, Haskell, Go etc) because errors and
>> errors handling is a very significant part of our programs that we just
>> cannot ignore. You can like or dislike them, you can always come up with
>> something very specific for your application or library. But the key idea
>> here is that core functionality is a rule of thumb for libraries &
>> ecosystem in general. So, when I do pick up library I can assume by default
>> the way 

Re: An Error spec?

[Oleksii Kachaiev]

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 with an error" (Go) etc etc etc. You have to come 
up with your own way to distinguish bad and good result. And they will be 
different for different libraries. And that's right the problem I've stated 
in my message. No unification means manually work in each use case.

2. The standard library throws exceptions even when the error might be 
conveyed as the result of the call. Probably because of #1 - there's no way 
to express that.. Well... except exceptions. So, we're running circles here.

BR,

On Saturday, October 27, 2018 at 12:48:27 AM UTC+3, Sean Corfield wrote:
>
> 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. Calling code should 
> check the return value to see if the library/function failed in one of the 
> expected, known, documented ways it is known to be possible to fail in, and 
> respond accordingly.
>
>  
>
> The latter can (and should) use exceptions. An exception says “I got into 
> a state I can’t handle because I wasn’t expecting to get there!” and maybe 
> the caller can handle that and maybe it can’t. Library/function authors can 
> help callers here by:
>
>  
>
>1. Providing a clear but succinct message for the exception,
>2. And providing as much potentially useful detail in the ex-data as 
>possible.
>
>  
>
> Does Java (and its standard library) overuse exceptions? Yes, absolutely. 
> It throws exceptions for all sorts of completely predictable failure modes. 
> We don’t need (or want) to be Java.
>
>  
>
> Clojure provides perfectly good features to support both the expected and 
> the unexpected failure modes and, in particular, provides an excellent way 
> to convey information about the point of failure even when our code doesn’t 
> know how to recover.
>
>  
>
> As Alex says, there may be value in providing a spec in your library for 
> the sort of ex-data you provide around exceptions. You’ll already be in 
> “regular Clojure land” as far as functions that return values that may 
> indicate success or expected, known failure modes.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Oleksii Kachaiev  >
> *Sent:* Friday, October 26, 2018 2:28:35 PM
> *To:* Clojure
> *Subject:* Re: An Error spec? 
>  
> 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 testable functions as much as we can... and at the same 
> time declaring the "official" way of handling errors using exceptions, 
> which are side-effects by their nature, even tho' they play really poorly 
> with: 
>
> * laziness (which is a default behavior for most operations with most 
> collections in the language)
>
> * multi-threaded code (especially in case of "opaque" jumps between 
> threads/executors when using core language concurrency primitives, or even 
> trying to emulate async event loop, i.e. with core.async)
>
> * macros (often macroexpand screws up the only feature we love about 
> exceptions: traces, making them pretty much useless) 
>
> I thought that the design approach of using data and staying declarative 
> should also be applied to errors handling. And a contract declared for a 
> function should reflect not only "the happy path" but all potential cases. 
> We see a lot of languages put some mechanics into the core library or 
> language design (i.e. Scala, Rust, Haskell, Go etc) because errors and 
> errors handling is a very significant part of our programs that we just 
> cannot ignore. You can like or dislike them, you can always come up with 
> something very specific for your application or library. But the key idea 
> here is that core functionality is a rule of thumb for libraries & 
> ecosystem in general. So, when I do pick up library I can assume by default 
> the way errors are handled. Most probably my code and libraries that I'm 
> already using would play nicely with each other. Which is not the case in 
> Clojure. As a creator of a few Clojure libraries, I always have to design 
> upfront what my library will do with errors, either 

RE: An Error spec?

[Sean Corfield]

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. Calling code should check 
the return value to see if the library/function failed in one of the expected, 
known, documented ways it is known to be possible to fail in, and respond 
accordingly.

The latter can (and should) use exceptions. An exception says “I got into a 
state I can’t handle because I wasn’t expecting to get there!” and maybe the 
caller can handle that and maybe it can’t. Library/function authors can help 
callers here by:


  1.  Providing a clear but succinct message for the exception,
  2.  And providing as much potentially useful detail in the ex-data as 
possible.

Does Java (and its standard library) overuse exceptions? Yes, absolutely. It 
throws exceptions for all sorts of completely predictable failure modes. We 
don’t need (or want) to be Java.

Clojure provides perfectly good features to support both the expected and the 
unexpected failure modes and, in particular, provides an excellent way to 
convey information about the point of failure even when our code doesn’t know 
how to recover.

As Alex says, there may be value in providing a spec in your library for the 
sort of ex-data you provide around exceptions. You’ll already be in “regular 
Clojure land” as far as functions that return values that may indicate success 
or expected, known failure modes.

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Oleksii 
Kachaiev 
Sent: Friday, October 26, 2018 2:28:35 PM
To: Clojure
Subject: Re: An Error spec?

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 testable 
functions as much as we can... and at the same time declaring the "official" 
way of handling errors using exceptions, which are side-effects by their 
nature, even tho' they play really poorly with:

* laziness (which is a default behavior for most operations with most 
collections in the language)

* multi-threaded code (especially in case of "opaque" jumps between 
threads/executors when using core language concurrency primitives, or even 
trying to emulate async event loop, i.e. with core.async)

* macros (often macroexpand screws up the only feature we love about 
exceptions: traces, making them pretty much useless)

I thought that the design approach of using data and staying declarative should 
also be applied to errors handling. And a contract declared for a function 
should reflect not only "the happy path" but all potential cases. We see a lot 
of languages put some mechanics into the core library or language design (i.e. 
Scala, Rust, Haskell, Go etc) because errors and errors handling is a very 
significant part of our programs that we just cannot ignore. You can like or 
dislike them, you can always come up with something very specific for your 
application or library. But the key idea here is that core functionality is a 
rule of thumb for libraries & ecosystem in general. So, when I do pick up 
library I can assume by default the way errors are handled. Most probably my 
code and libraries that I'm already using would play nicely with each other. 
Which is not the case in Clojure. As a creator of a few Clojure libraries, I 
always have to design upfront what my library will do with errors, either with 
my own implementation or embracing/adopting one of the existing libraries to 
handle control flows. And each time I'm struggling with the choice because I 
know perfectly well that a) most other libraries in the ecosystem would not be 
aligned with it automatically, b) most applications/users will be forced to 
learn how to deal with the control flow in this specific case. More libraries 
you use = more cases of how errors are handled here and there = more time you 
need to teach them to talk to each other. It seems to me that the "write about 
your exceptions in the documentation and pray all users of your code will read 
that carefully and think through really hard" approach (which is the state of 
the art right now) makes ecosystem of the language & libraries more fragile and 
more fragmented than it might be.

Thanks,

On Friday, October 26, 2018 at 10:42:13 PM UTC+3, Sean Corfield wrote:

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 

Re: An Error spec?

[Oleksii Kachaiev]

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 testable functions as much as we can... and at the same 
time declaring the "official" way of handling errors using exceptions, 
which are side-effects by their nature, even tho' they play really poorly 
with:

* laziness (which is a default behavior for most operations with most 
collections in the language)

* multi-threaded code (especially in case of "opaque" jumps between 
threads/executors when using core language concurrency primitives, or even 
trying to emulate async event loop, i.e. with core.async)

* macros (often macroexpand screws up the only feature we love about 
exceptions: traces, making them pretty much useless) 

I thought that the design approach of using data and staying declarative 
should also be applied to errors handling. And a contract declared for a 
function should reflect not only "the happy path" but all potential cases. 
We see a lot of languages put some mechanics into the core library or 
language design (i.e. Scala, Rust, Haskell, Go etc) because errors and 
errors handling is a very significant part of our programs that we just 
cannot ignore. You can like or dislike them, you can always come up with 
something very specific for your application or library. But the key idea 
here is that core functionality is a rule of thumb for libraries & 
ecosystem in general. So, when I do pick up library I can assume by default 
the way errors are handled. Most probably my code and libraries that I'm 
already using would play nicely with each other. Which is not the case in 
Clojure. As a creator of a few Clojure libraries, I always have to design 
upfront what my library will do with errors, either with my own 
implementation or embracing/adopting one of the existing libraries to 
handle control flows. And each time I'm struggling with the choice because 
I know perfectly well that a) most other libraries in the ecosystem would 
not be aligned with it automatically, b) most applications/users will be 
forced to learn how to deal with the control flow in this specific case. 
More libraries you use = more cases of how errors are handled here and 
there = more time you need to teach them to talk to each other. It seems to 
me that the "write about your exceptions in the documentation and pray all 
users of your code will read that carefully and think through really hard" 
approach (which is the state of the art right now) makes ecosystem of the 
language & libraries more fragile and more fragmented than it might be.

Thanks,

On Friday, October 26, 2018 at 10:42:13 PM UTC+3, Sean Corfield wrote:
>
> 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 callers might occasionally not be 
> able to ascertain a reason beyond “it failed”…
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Didier >
> *Sent:* Friday, October 26, 2018 11:35:20 AM
> *To:* Clojure
> *Subject:* RE: An Error spec? 
>  
> 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 compute was 
> corrupted, or missing, etc. And say this producing service has no user 
> facing component, failing it is not logical. So I need to publish the 
> partial result, and the error field should indicate an error. In my case it 
> publishes a document entry in a nosql datastore, and events about it.
>
> Now, some other system will eventually consume that document, to display 
> it to the user. When it does, it must appropriately handle the fact that 
> some fields were in error.
>
> My documents are fully specced. So that consuming services can easily know 
> their shapes and structure, so they can be sure to support them fully.
>
> In such scenario, exceptions aren't useful, but only because Java 
> exceptions are crap at serialization. So I need to do the same thing you 
> are, marshal my exception into an error and serialize that into my 
> document. Then I spec the field appropriately. 
>
> Now, I feel a lot of people using Spec would have such a use case, as its 
> a logical tool to model data at your boundaries, 

RE: An Error spec?

[Sean Corfield]

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 callers might occasionally not be able to 
ascertain a reason beyond “it failed”…



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Didier 

Sent: Friday, October 26, 2018 11:35:20 AM
To: Clojure
Subject: RE: An Error spec?

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 compute was corrupted, or missing, 
etc. And say this producing service has no user facing component, failing it is 
not logical. So I need to publish the partial result, and the error field 
should indicate an error. In my case it publishes a document entry in a nosql 
datastore, and events about it.

Now, some other system will eventually consume that document, to display it to 
the user. When it does, it must appropriately handle the fact that some fields 
were in error.

My documents are fully specced. So that consuming services can easily know 
their shapes and structure, so they can be sure to support them fully.

In such scenario, exceptions aren't useful, but only because Java exceptions 
are crap at serialization. So I need to do the same thing you are, marshal my 
exception into an error and serialize that into my document. Then I spec the 
field appropriately.

Now, I feel a lot of people using Spec would have such a use case, as its a 
logical tool to model data at your boundaries, and so I felt it might make 
sense to offer a spec macro for it.

--
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Error spec?

[Alex Miller]

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:20 PM UTC-5, Didier wrote:
>
> 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 compute was 
> corrupted, or missing, etc. And say this producing service has no user 
> facing component, failing it is not logical. So I need to publish the 
> partial result, and the error field should indicate an error. In my case it 
> publishes a document entry in a nosql datastore, and events about it.
>
> Now, some other system will eventually consume that document, to display 
> it to the user. When it does, it must appropriately handle the fact that 
> some fields were in error.
>
> My documents are fully specced. So that consuming services can easily know 
> their shapes and structure, so they can be sure to support them fully.
>
> In such scenario, exceptions aren't useful, but only because Java 
> exceptions are crap at serialization. So I need to do the same thing you 
> are, marshal my exception into an error and serialize that into my 
> document. Then I spec the field appropriately. 
>
> Now, I feel a lot of people using Spec would have such a use case, as its 
> a logical tool to model data at your boundaries, and so I felt it might 
> make sense to offer a spec macro for it.
>
>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: An Error spec?

[Didier]

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 compute was corrupted, or missing, 
etc. And say this producing service has no user facing component, failing it is 
not logical. So I need to publish the partial result, and the error field 
should indicate an error. In my case it publishes a document entry in a nosql 
datastore, and events about it.

Now, some other system will eventually consume that document, to display it to 
the user. When it does, it must appropriately handle the fact that some fields 
were in error.

My documents are fully specced. So that consuming services can easily know 
their shapes and structure, so they can be sure to support them fully.

In such scenario, exceptions aren't useful, but only because Java exceptions 
are crap at serialization. So I need to do the same thing you are, marshal my 
exception into an error and serialize that into my document. Then I spec the 
field appropriately. 

Now, I feel a lot of people using Spec would have such a use case, as its a 
logical tool to model data at your boundaries, and so I felt it might make 
sense to offer a spec macro for it.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] 1.10.0-beta4

[Ghadi Shayban]

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 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 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 had a lot of other changing going to production lately that have 
>> changed the performance dynamic of three of our servers, so any performance 
>> boost from 1.10 and the 8+ bytecode would likely have been swamped by other 
>> changes).
>>
>>  
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] 1.10.0-beta4

[Alex Miller]

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 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 had a lot of other changing going to production lately that have 
> changed the performance dynamic of three of our servers, so any performance 
> boost from 1.10 and the 8+ bytecode would likely have been swamped by other 
> changes).
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: An Error spec?

[Sean Corfield]

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.



With just a small tweak on how the middleware works, we could easily replace 
the handler error logic with throw of ex-info (with appropriate data) and 
probably simplify our code.



Which is to say: I agree with Alex that exceptions are the idiomatic way to go 
in Clojure and ex-info / ex-data (and now ex-message and ex-cause) provide all 
the hooks you need for conveying error information along with those exceptions.



Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




From: clojure@googlegroups.com  on behalf of Didier 

Sent: Thursday, October 25, 2018 11:32:12 PM
To: Clojure
Subject: Re: An Error spec?

Interesting. I understand that, I guess it's because of my usage of spec.

I tend to use spec exclusively at the boundaries. Think serialization. 
Sometimes, I have a producer which can't handle the error, so it must be 
serialized and exchanged to the consumer.

So say the producer couldn't produce the value, for some reason. In some cases, 
that's a bug, and I throw an exception, and fail the producer itself. But 
sometimes, its an expected possibility, in which case, tbe value is an error. 
And the producer must communicate that out.

Unfortunatly, exceptions are not friendly to serialization or spec. So I need 
to roll my own error structure, serialize that, and spec it.

--
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [ANN] 1.10.0-beta4

[Sean Corfield]

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 had a lot of other 
changing going to production lately that have changed the performance dynamic 
of three of our servers, so any performance boost from 1.10 and the 8+ bytecode 
would likely have been swamped by other changes).

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com  on behalf of Alex 
Miller 
Sent: Friday, October 26, 2018 5:28:26 AM
To: clojure@googlegroups.com
Subject: Re: [ANN] 1.10.0-beta4

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 
mailto:corporate.piy...@gmail.com>> wrote:

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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google 
Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/dLUUiy_RzGk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mail queue thread

[Erik Assum]

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 emails]
  (send-email ctx email))

So now you could do something like 

(let [emails (read-unsent-emails! [db])]
 (doseq [email emails]
   (send-email ctx email)))

put that in a main, create a uberjar and make a cronjob which runs every 5 
minutes.

Or, you could as you suggest do it in a scheduler, I think I’ve used a clojure 
wrapper for quartz previously.
but I know the people from Juxt has some stuff that might be nice as well.

Or you could use make a transducer, (map (partial send-email ctx), and use that 
on your async channel.

Erik.

> On 26 Oct 2018, at 15:05, brj...@gmail.com wrote:
> 
> You are quite right. My plan is to save emails that must be sent (not all 
> need guaranteed delivery) to a database but queue them right away in a worker 
> thread. The DB will then be updated with delivery status. In the interest of 
> reducing IO, I would prefer not to have to write and read from the DB for all 
> emails but only in case of a crash or mail server down something similar. So 
> there needs to be continuous monitoring of the email table - which requires 
> some sort of ever running task? Would you suggest a go block or using a 
> scheduler (there seem to be quite a few options of Clojure schedulers).
> 

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mail queue thread

[James Reeves]

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 for not handling it in your "send-email!"
function?

-- 
James Reeves
booleanknot.com

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Mail queue thread

[brjann]

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 to
take care of the result

(let [c (chan)
  (send-email! {:mail mail :channel c})
  (go
 (let [res ( wrote:

> Not knowing your app nor your requirements, but it might also be an idea
> to separate concerns:
>
> Your web-app could store “emails to be sent” in a database table, and you
> could have a different process reading this table at regular intervals and
> sending mails, and also marking the emails as sent, failed, or what have
> you. Maybe even a time stamp to indicate when an email was sent.
>
> This gives you a couple of benefits:
> 1) a simpler web app
> 2) a chance to resend emails
> 3) easier testing, as you can see that the web-app stores the mails it
> should in the db, without actually sending emails
>
> HTH,
>
> Erik.
> --
> i farta
>
> 25. okt. 2018 kl. 17:46 skrev brj...@gmail.com:
>
> Hi,
>
> First, I would like to briefly present myself to the list. I'm a
> psychologist and researcher at the Karolinska Institutet in Stockholm,
> Sweden. I do research within the field of internet-based psychological
> treatment - which is a field that has grown a lot during the last 10-15
> years. I have developed my own web platform to deliver these treatments to
> patients with different mental and medical conditions. I wrote the first
> version in PHP, and not being a professional programmer, the code base is a
> big mess after > 10 years of development.
>
> Two years ago, a friend introduced me to Clojure. I had never worked with
> a lisp before, but I quickly fell completely in love with it. So many of
> the issues of programming in PHP completely disappeared! Words cannot
> express my gratitude to Rich for inventing Clojure, the core team, all
> developers out there who write extremely useful libraries, and my friend
> for introducing Clojure to me.
>
> I decided to completely rewrite my web platform in Clojure. I've chosen to
> do a gradual move from PHP to Clojure, meaning that I replace PHP code with
> Clojure code component by component and continuously test in production.
> Like I said, I'm not a professional programmer, and this venture poses a
> lot of challenges. I try to read everything I find in books and on the web,
> but when it comes to more complex issues, such as threads and async
> programming, I feel that I end up almost guessing and with a lot of trial
> and error. I have no idea how cautious one should be when launching a new
> thread (while it completely occupy the server???) and am often surprised
> when my go blocks suddenly freeze. I feel that I am at the mercy of the
> Clojure community if I want to understand these (and many other!) issues.
>
> This leads me to the subject of this email. I've decided to migrate my
> mail queue from PHP to Clojure. In PHP, it's just a cron job that executes
> every five minutes to send all emails (and actually also SMS-messages, but
> not really relevant) that have been queued.
>
> I've written a basic mock Clojure implementation with the following goals
> - All messages should be sent async, i..e, the web user should not have to
> wait while the email is being sent. -> I'm sending them in a separate
> thread.
> - I have a fear that if I have a thread dedicated only to sending emails,
> I'm wasting server resources. -> I want the thread to die 5 seconds after
> the last email in the queue has been sent.
>
> My implementation basically consists of
> - An eternal go loop that receives a notification through a channel if new
> messages have been queued
> - The go loop checks if the mail sender thread is running. If not, it
> starts it.
> - The mail sender thread dies 5 secs after the last email was sent
> - The state of the thread (running / not running) is stored in an agent to
> avoid race conditions (i.e., starting multiple threads or not starting a
> thread because it is running when its status is checked but stops right
> after).
>
> My code is here
> https://gist.github.com/brjann/2aef16849b9bd445374cb6b31efece60
>
> If any of you have had the time and energy to read this far (including the
> code), I would be very grateful for your input.
> - Is there a risk that my go block will hang?
> - Have I eliminated the risk for race conditions?
> - Do I really need to kill the thread or is there no risk for thread
> starvation on the server (I will probably
> - Could I use send instead of send-off? I guess that I am now using two
> threads, one for the sender and one each time I send a message using
> send-off.
> - Any newbie mistakes / coding style issues?
> - Could this be done in a better/simpler way???
>
> (Btw, I would be very grateful for feedback on the form of my question if
> you have any. Are there better/other forums? Could I present 

Re: An Error spec?

[Alex Miller]

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 it would make sense to say much 
about the exception anyways, although the one place I sometimes want 
something is a spec for ex-data thrown.)

I understand monadic errors are natural in other language communities, and 
certainly there is nothing stopping you from using that approach. But 
similarly, we're not going to add anything to spec for it. If it works for 
you, great!

On Friday, October 26, 2018 at 4:22:36 AM UTC-5, Serzh Nechyporchuk wrote:
>
> 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 
> "monadic" errors feels very natural when you are using spec.
>
> On Friday, October 26, 2018 at 6:53:31 AM UTC+3, Alex Miller wrote:
>>
>> This is not a pattern that we encourage in Clojure. The standard 
>> mechanism for error reporting is exceptions, which are not spec'ed.
>>
>> On Thursday, October 25, 2018 at 8:46:54 PM UTC-5, Didier wrote:
>>>
>>> I've started to see a pattern in my spec like this:
>>>
>>> (s/or :success string?
>>>   :error ::error)
>>>
>>> And I've been tempted to create my own spec macro for this. But I also 
>>> thought, maybe Spec itself should have such a spec.
>>>
>>> (s/error  )
>>>
>>> What do people think?
>>>
>>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] 1.10.0-beta4

[Alex Miller]

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 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 moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/dLUUiy_RzGk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] 1.10.0-beta4

[Piyush Katariya]

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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Error spec?

[Serzh Nechyporchuk]

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 
"monadic" errors feels very natural when you are using spec.

On Friday, October 26, 2018 at 6:53:31 AM UTC+3, Alex Miller wrote:
>
> This is not a pattern that we encourage in Clojure. The standard mechanism 
> for error reporting is exceptions, which are not spec'ed.
>
> On Thursday, October 25, 2018 at 8:46:54 PM UTC-5, Didier wrote:
>>
>> I've started to see a pattern in my spec like this:
>>
>> (s/or :success string?
>>   :error ::error)
>>
>> And I've been tempted to create my own spec macro for this. But I also 
>> thought, maybe Spec itself should have such a spec.
>>
>> (s/error  )
>>
>> What do people think?
>>
>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Releasing d2q, a simple, efficient, generally applicable engine for implementing graph-pulling API servers in Clojure. Feedback wanted!

[Val Waeselynck]

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 could make that look cleaner. 
>

I'm a bit reluctant to do that - I'm afraid it may make the code a bit too 
'magical'. In my experience, you don't write Resolver Functions very often 
in practice - instead, you make a few very generic factories for Resolver 
Functions (like this one 

 
in the SQL example) and the occasional specific Resolver Function (like this 
one 
,
 
also in the SQL example), and you use helpers like middlewares to make 
writing these Resolver Functions easier.
 

> I also think namespacing the d2q keywords would make it easier to scan
>

The rationale for that is to be able to use Clojure Records for efficiency, 
and also friendliness to other client languages than Clojure. But, hey, don't 
get me started 

 
on that :)
 

> .
> - I'd put query expressiveness and real-world examples (authorization, 
> more complex schemas, etc) as tied for most important future work.
>

Thanks, regarding real-world examples, have you seen the d2q-examples repo? 
https://github.com/alvalval/d2q-examples  


>
> I'm eager to see where you take this library.
>
> On Thursday, October 25, 2018 at 4:45:57 AM UTC-4, Val Waeselynck wrote:
>>
>> I'm happy to release d2q , a 
>> library for implementing graph-pulling server backends, playing in the same 
>> space as Lacinia or Pathom 
>> , with an emphasis on simplicity, 
>> generality and performance:
>>
>> https://github.com/alvalval/d2q
>>
>> This library has been used internally on a previous project for months, 
>> I've just removed the application-specific parts and added documentation.
>>
>> Before developing this any further, I'm now looking for feedback:
>>
>>- 
>>
>>Do you find the value proposition clear and appealing?
>>- 
>>
>>Any criticism of the design choices?
>>- 
>>
>>I see many potential directions for future development, which are 
>>important to you? (enhance query expressiveness with new features / 
>> better 
>>docs / add specs / integration with GraphQL or Om.Next / more helpers for 
>>integrating data sources)
>>
>> Cheers,
>>
>

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An Error spec?

[Didier]

Interesting. I understand that, I guess it's because of my usage of spec.

I tend to use spec exclusively at the boundaries. Think serialization. 
Sometimes, I have a producer which can't handle the error, so it must be 
serialized and exchanged to the consumer.

So say the producer couldn't produce the value, for some reason. In some cases, 
that's a bug, and I throw an exception, and fail the producer itself. But 
sometimes, its an expected possibility, in which case, tbe value is an error. 
And the producer must communicate that out.

Unfortunatly, exceptions are not friendly to serialization or spec. So I need 
to roll my own error structure, serialize that, and spec it.

-- 
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 moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.