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 <clojure@googlegroups.com> on behalf of Oleksii Kachaiev <kacha...@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<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<mailto: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.
