An Error spec?

[Didier]

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 <success-spec> <error-spec>)

What do people think?

[Alex Miller]

This is not a pattern that we encourage in Clojure. The standard mechanism for error reporting is exceptions, which are not spec'ed.

[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.

[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.

[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!

[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: clo...@googlegroups.com <clo...@googlegroups.com> on behalf of Didier <did...@gmail.com>
Sent: Thursday, October 25, 2018 11:32:12 PM
To: Clojure
Subject: Re: An Error spec?

 

--
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.

[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.

[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.

[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: 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?

 

[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,

[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: 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?

[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,

[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

[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.<namespace> 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”.

 

2. 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: clo...@googlegroups.com <clo...@googlegroups.com> on behalf of Oleksii Kachaiev <kach...@gmail.com>

Sent: Friday, October 26, 2018 3:02:54 PM

[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.

[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: clo...@googlegroups.com <clo...@googlegroups.com> on behalf of Didier <did...@gmail.com>

Sent: Friday, October 26, 2018 8:45:23 PM

To: Clojure
Subject: 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.")

[Max Penet]

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
>
>  
>
>
>

[Max Penet]

There is one context where failure as exceptions can be a bit ugly is in core async channels but there are a few ways to deal with this, from separating channels for exceptions, using some kind of named tuple, map or just dispatching with instance? It is just a side effect of core async design where every message is just a value with no specific meaning (which is a good thing imho).

[Oleksii Kachaiev]

Given that the examples you provided are from typed languages and Clojure isn’t typed, what would satisfy you here?

Well... static types have absolutely nothing to do with errors handling mechanics. That's just a way for your compiler to check if you glue all pieces together in a reasonable way during compilation. That's it. Golang is a good example as it doesn't use types to declare good or bad results. It uses 2 return values (result, nil) or (nil, error). And one more interesting observation here: even tho' you don't need a "special" error type as you're free to put anything there (at the end of the day that's just a convention you can ignore), Golang still provides standard errors.* package to deal with errors represented as data.

We don't have tuples or static types in Clojure but we have protocols, deftype, vectors & keywords, maps & keywords. We can also go further and implement that in Java if we care about low-level performance and/or interoperability. I think that protocol is a really good approach here as it empowers you with a really fine-grained control of what you treat as an error value still keeping that composable with different abstractions. 

First off, a nitpick: Clojure doesn’t have a standard library. 

That's' pretty irrelevant for this particular conversation, but I still think that such a juggling with terms is unnecessary speculative. If I wrote `(map str (range 5))`, I assume `map`, `str` and `range` are defined somewhere in a way I don't need to plug-in an external library to make this happen. You can call this "core", "stdlib", "standard library" or whatever. It doesn't change the essence of the problem I've described. 

there are a few ways to deal with this

If I got your message correctly, what you're suggesting is actually NOT TO USE exceptions with core.async. Which is true. As I stated in my first message, core.async is a great example of the context where exceptions don't work. And I personally don't see any way to make them work. But if we promote exceptions as an official way/best practice and don't anything else, then you have to expect most of your code and most of the libraries you're using to throw something here and there. It's not that simple to protect yourself from exceptions, unfortunately. Going further. If we choose not to use exception... we're right here, in the no men land where no rules are defined and everyone on their own. Which right what I was talking about. 

  

[alex]

How about using exception instances as errors? That plays pretty nicely with ex-info and (try ... (catch Exception e e)). I've built https://github.com/dawcs/flow on top of that approach  and that seems like pretty good abstraction. Despite I'm not sure about CLJS.

Anomalies are also great and you may check out https://github.com/dawcs/anomalies-tools for some tooling around it. But you may still need a bridge to convert exceptions caught from 3rd-party java libs into anomalies structure. And despite Cognitect roots, it doesn't feel like "official standard".  

пятница, 26 октября 2018 г., 4:46:54 UTC+3 пользователь Didier написал:

[Sean Corfield]

Flow reminds me a bit of a project I started in early 2015 and decided to sunset in late 2016: https://github.com/seancorfield/engine

 

We actually used Engine at work for a while but decided the resulting code was both harder to read and not really very idiomatic. I’ll be interested to hear how people find Flow in production – it’s a lot more focused and simpler than Engine (which is definitely a good thing! 😊 ).

 

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 alex <fmn...@gmail.com>
Sent: Wednesday, November 7, 2018 2:05:28 PM

To: Clojure
Subject: Re: An Error spec?

[alex]

Thanks Sean, simple api is really main goal in Flow design. Initially we had much more sugar, but resulting version is pretty concise. We use it in production at Eventum, mostly in graphql resolvers/mutations and we're quite happy with it. 

четверг, 8 ноября 2018 г., 21:18:18 UTC+2 пользователь Sean Corfield написал:

[Sean Corfield]

Alex, I’m curious, should this https://github.com/dawcs/flow/blob/master/src/dawcs/flow.clj#L53 use *exception-base-class* rather than Throwable directly?

 

It looks very interesting and elegant – I’ll probably give this a test drive next week!

 

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 alex <fmn...@gmail.com>
Sent: Wednesday, November 7, 2018 2:05:28 PM
To: Clojure
Subject: Re: An Error spec?

 

[alex]

Sean, thanks for your feedback! Instance of Throwable is fail anyway and I can't imagine a situation when it's not. *exception-base-class* only sets behavior of call  - what we should catch and what will be thrown. Probably naming is kinda ambiguous here and *exception-base-class* should be called *catch-from* to make its purpose more clear without reading docstring.

пятница, 9 ноября 2018 г., 8:05:18 UTC+2 пользователь Sean Corfield написал:

[Sean Corfield]

Ah, that makes much more sense. Got it!

 

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 alex <fmn...@gmail.com>

Sent: Friday, November 9, 2018 12:23:50 AM