It's arguable. Exceptions give you a somewhat clean way of pattern match their type and dealing with failures in a single place in an uniform way. Ex having to deal with not ok http status codes and then a potential low level networking exception at the same level is good imho.
I tend to use ex-info a lot lately, if you throw in some helpers it becomes quite clean/powerful. I wrote a little library that adds a clojure hierarchy on top of it and you then have a decent way of doing exception 'inheritance' via ex-info/ex-data. https://github.com/mpenet/ex On Friday, October 26, 2018 at 11:48:27 PM UTC+2, Sean Corfield wrote: > For any library – for any function – there are always two classes of unhappy > path: > > > > Expected, known failure modes.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: > > > > Providing a clear but succinct message for the exception,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 <clo...@googlegroups.com> on behalf of Oleksii > Kachaiev <kach...@gmail.com> > > 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 > 😊 > > > > 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 <clo...@googlegroups.com> on behalf of > Didier <did...@gmail.com> > > 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 > > 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 > > 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. > > 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 clo...@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+u...@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+u...@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.
