curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: usefulness of UnhandledErrorListener
Date Tue, 09 Sep 2014 15:49:24 GMT
It’s called when Curator is giving up. There’s no requirement that you add an UnhandledErrorListener.
It’s only if you want the notification.

-JZ


On September 9, 2014 at 10:37:59 AM, Joel Denny (jdenny@etinternational.com) wrote:

What's an example of a worst case error?  Is it possible to distinguish them from other errors
that are normally handled elsewhere?  For example, I see that connection loss can be caught
here and by Curator API calls in other threads at the same time.

Thanks for your help.

On 09/09/2014 11:25 AM, Jordan Zimmerman wrote:
It’s not really very useful. I put it in there in the unlikely case that someone wanted
to handle a worst case error. The errors get logged regardless.

-JZ


On September 9, 2014 at 10:24:09 AM, Joel Denny (jdenny@etinternational.com) wrote:

Hi,

I am trying to decide whether I need to add an UnhandledErrorListener to
my Curator application in order to guarantee graceful handling of
connection loss or other failures.

At http://curator.apache.org/errors.html, I see the following paragraph:


"UnhandledErrorListener is called when a background task, etc. catches
an exception. In general, Curator users shouldn't care about these as
they are logged. However, you can listen for them if you choose."


What is the purpose then of an UnhandledErrorListener? Is it purely for
any custom logging that a Curator user might wish to perform? Are there
any known use cases where it is worthwhile to catch and handle
exceptions in some other manner here?

Thanks.

Joel



Mime
View raw message