So when you have something like this:
queue.subscribe(ack: true) do |info, message, json|
if rand > 0.5
When that raise happens, the subscription will never receive anything afterwards because the thread is dead in the water and Thread#abort_on_exception isn't turned on (from what I can tell).
I feel like subscribe should have a way to say how to handle errors or tack on something like on_exception for subscriptions.
I've combed issues / doc / code and I haven't seen anything so I'm wondering if this is something I'm doing also.
I can confirm that basic.deliver is dispatched without exception handling. basic.cancel is.
Java client has exception handlers and the default one simply dumps exceptions to stderr. We should do the same.
For now I just wrap my inner subscribe block with a begin / rescue and notify our exceptions service there.
Do you have a link to the java client handling or example? For us we'd love to have library support for exception handling as we use this library pretty extensively.
See javadoc. You define exception handler per connection. There is a default handler that dumps stack traces to stderr.
Tests for #186
Delegate uncaught consumer exceptions to exception handler
This is what Java and C# clients do.
Awesome, thanks for the quick response.