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 ([email protected]) 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 ([email protected]) 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
