No, don't do that. Create an error response map and attach that the the context in a handler or interceptor.

In no language do you want to use exceptions as a flow of control method.

http://pedestal.io/reference/response-map

http://pedestal.io/reference/context-map#_as_applied_to_http But the docs could be clearer about this "attach a :response" behavior. It's kind of implied and scattered, and needs to be brought into better focus.

Thanks for the reply @hlship, much appreciated. That suits me, I like to use exceptions for unexpected events. Ya, agreed, the pedestal docs could be viewed as somewhat misleading here. Maybe an example app somewhere could serve as guidance for error flow handling? Do you know of any?

Yes I think it's a very elegant approach to throw exceptions and use one :error handler to return the appropriate response. This is idiomatic pedestal code as the example on that documentation page shows. Advice to not throw exceptions for control flow is dogmatic. There are very wise opinions, with arguments to back them up, stating the exact opposite, I found this exegesis enlightening https://grishaev.me/en/clj-book-exceptions/#when-to-throw-exceptions

Interesting, thanks for a differing perspective @danvingo.

My interest is to conform to what pedestal was designed to support. But maybe pedestal itself does not have a strong opinion on error flow.

For what it's worth I use exceptions + cognitect-labs/anomalies a lot with pedestal, especially for input validation, to give the correct context to the user in case of an error. I think it's a nice way to separate concerns. The code that knows about the error throws an ex-info with the context map (:category of anomaly and extra info) and the code that's responsible for sending back a response to the client reads the ex-data of the exception and decides the type of response based on the category of the anomaly.

Thanks @pavlos, I've been meaning to look into cognitect anomalies.... now that is one https://github.com/cognitect-labs/anomalies/blob/master/src/cognitect/anomalies.cljc library!

@hlship I'm exploring: > Create an error response map and attach that the the context in a handler or interceptor. That's cool. The docs imply that the interceptor :error is called only on a thrown exception, but it is also called when an interceptor sets :io.pedestal.interceptor.chain/error in the context. Also, to me anyway, the docs imply that the value for :io.pedestal.interceptor.chain/error should be an Exception, but you are suggesting it could be a simple map.

No I'm not. :io.pedestal.interceptor.chain/error is for thrown exceptions, :response is for a response map. I don't think that user code should ever set the ::error key, but user code should absolutely set the :response key.

As soon as any interceptor sets the :response key, or after a handler returns a response map (which is the same thing from Pedestal's point of view), execution switches to :leave mode, resulting in the response map turning into an HTTP response.

Ah, ok. Thanks. A sample app with error flow handling (exceptional and non-exceptional) would be awesome.

If I ever get to a point where I fully understand a sensible strategy, I would be happy to share that understanding as updates to pedestal docs.