Handle with destructuring support

[serefayar]

Hi, awesome work!

I'm trying to adapt the library in my last side project.

When I signal a condition as a map or record instead of an object or namespaced keyword, I would really like to match the handle also with destructuring support.

for example:

(handler-case  (signal {:type ::some-cond-type :some-key :some-value}) ;; as a map with the type key
               (signal ::cond-nskw {:some-key :some-value})
               (signal (RuntimeException. "An exception"))

 ([:type ::some-cond-type] [{:keys [some-key] :as others}] :ok) ;; like this
 (::cond-nskw [{:keys [some-key]}] :ok)
 (Exception [ex] :ok))

Do you think it would be a good feature? Thanks!

[IGJoshua]

Hey, thanks for showing interest in the library! It's not a feature I'd considered before, and I'd be curious to hear what kinds of things this would open up for developers, it doesn't seem like it's much more than a convenience that could be handled by a custom signal function.

In general the recommendation for handlers like this is to use kwargs, and using the & {} destructuring syntax also allows a trailing map that will be used for keyword arguments being filled.

I would potentially be open to extending the dispatch mechanism for handlers though to go beyond just using the global hierarchy.

As it stands though, the way I would handle this is to do as follows:

(defn my-signal
  [condition-map]
  (signal (:type condition-map) condition-map))

(handler-case (my-signal {:type ::some-cond-type :some-key :some-value})
  (::some-cond-type [_ & {:keys [some-key] :as others}] :ok))

If I were to extend the mechanism that's used for dispatch though, I think I would be most likely to make it into a protocol the condition type must implement taking the dispatch value as an argument. It would have default implementations for keywords and exceptions to keep existing behavior.

Is there something in particular that makes this extension (which would allow you to implement your own destructuring form) more desirable than just a custom signal function?

[serefayar]

Hey,

Actually, your example mostly satisfies my needs. Before I opened this thread, I'd made a pretty simple PoC for myself. It may not be close to what you think, for sure.

master...serefayar:farolero:master

My goal here is to use a data structure with a consistent abstraction as a condition for my whole project, and if necessary, to extend other data structures I want in the same way.

And beside the type, I would like to also have an option to match the condition with just a ns kw.

Thanks!

[IGJoshua]

That's a really cool PoC, and actually very similar to what I was considering in response to this request!

I'm going to spend a little more time thinking about it before I either merge that change or make some myself, but I really appreciate the work!

Since it sounds like my suggestion with a wrapper function around signal might satisfy your current needs, I probably won't put a rush on this and will spend some time thinking about it.