anomalies

> has no inherent error model I'll pitch in here, as I've been doing a lot of thinking about this issue and ended up writing my own (tiny) tools for handling anomalies, modeled on the very well thought-out https://github.com/cognitect-labs/anomalies categorization. This is actually a much wider problem and not specific to core.async. Handling anomalies is difficult. It used to be that you would have exceptions and errors which would be thrown, unwinding the stack. This pattern no longer works in asynchronous code, or code that needs to pass anomalies between the server and the client. In practical applications, an anomaly might need to be returned from a function, passed through a `core.async` channel, then thrown, unwinding the stack on the server side, then caught and passed to the client side over a WebSocket, and then displayed to the

An interesting development in this direction is Clojure’s anomalies taxonomy: nine outcomes (two retriable, two maybe-retriable, five non-retriable; nine respective ways to fix) See table here: https://github.com/cognitect-labs/anomalies

I'll do my best but there might be better explanations around the web. I think an illustrative example would be this repo: https://github.com/cognitect-labs/anomalies These are basically re-usable, namespaced keywords. You might decide to use them or something similar in your program/system and some people do. Pretty neat: Their semantics are documented in the readme and the little bit of code in the repo defines a spec here https://github.com/cognitect-labs/anomalies/blob/master/src/.... You can read it as: any map that has these keywords as defined in the spec is an "anomaly". Specs are open, non-exclusive so you can add more stuff to your structure and they still conform. (Note that the double colon before the keywords just mean "the current namespace defined at the top".) Note that you don't need to define a spec for namespaced keywor