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 <javascript:> <clo...@googlegroups.com > <javascript:>> on behalf of Didier <did...@gmail.com <javascript:>> > *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 clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > 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+u...@googlegroups.com <javascript:>. > 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.
