<div dir="ltr">On Wed, Aug 7, 2013 at 2:43 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>Bunny's automatic recovery is for network failures, not connection exceptions (which are rare<br>
and severe, and should be as visible as possible).<br></blockquote><div><br></div><div>I agree with you on the connection exceptions, in that case it makes a lot of sense to be loud. �However I was thinking in the case of a channel exception being thrown. �E.g., you have a consumer associated with a channel, and you happen to publish to a non-existent exchange, whoops that consumer goes away. Obviously the client code should be notified of the failure, but from an API perspective its annoying to have something that is potentially unrelated be affected and have to be recreated.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>I don't think this is a good idea. First, it is part of the protocol<br></div>
and developers may want to use that. Second, error handling for operations such as queue.declare<br>
or basic.publish, is per-channel. Finally, basic.qos setting, delivery tags and publisher confirms<br>
are all per-channel.<br></blockquote><div><br></div><div>That makes me wonder what is it that developers use channels for? �My understanding is they're were designed to be an 'error scope' at a protocol level. I don't see a lot of developers using them that way, and sometimes its the source of a bit of pain (having to recreate any resources that get destroyed as a result of a channel exception, or in bad cases, their whole app aborts because the channel dies).</div>
<div><br></div><div>My thinking is that an API could be created that internally uses channels intelligently to give more native feel to error handling. One example of changing the API might be: instead of apply basic.qos to a channel, you apply it to a consumer, and internally the library maps a consumer to a channel, so a BasicQos on a consumer. �The same can be done for other aspects of the protocol (this is what I ended up doing with SimpleAmqpClient). �A downside being the API may not map 1:1 �to a lot of the documentation that is out there.</div>
<div><br></div></div></div></div>