curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesha Sudasingha <>
Subject Re: Why do you throw exceptions of class Exception
Date Wed, 23 Nov 2016 01:05:23 GMT
I agree with you to some extent. But doesn't it feel bad as a design to use
*Exception* class? A text quoted from mail archive posted by *John Vines*,

By declaring thrown Exception, we force consumers to also catch
> RuntimeExceptions instead of letting them propagate as they normally would.
> In some cases, the calling code may need to attempt roll-back semantics, or
> retry outside of what Curator provides, or something else that we haven't
> thought of.

> I'd like to propose replacing much of the thrown Exception methods with
> CuratorException. This will still carry the connotation that it doesn't
> matter what kind of exception we encounter, they're all bad. It will also
> be backwards compatible with the previous API, since users will still be
> able to catch Exception in their calling code. And it has the advantage of
> separating checked exceptions from unchecked ones, so that users don't
> unintentionally catch something unrelated.

What is your opinion on the above?

On 22 November 2016 at 20:44, Jordan Zimmerman <>

> It’s just an accident of history. At the time, it seemed like the right
> thing to do. Ultimately, checked exceptions don’t work well. I still feel
> that explicit exception specifications are a pain-in-the-butt. So, if a
> method must throw an exception, throwing Exception is simpler to deal with.
> If I could redo things I’d get rid of checked exceptions altogether. Jersey
> 2.0 is not a bad way to handle these things. Everything is
> WebApplicationException which extends RuntimeException, not Exception.
> -JZ
> On Nov 22, 2016, at 6:39 AM, Flavio Junqueira <> wrote:
> I have actually come across the same thing and have been wondering why it
> is throwing a generic exception. Even if it is executing user code, it
> could still wrap it with something like CuratorException.
> If anyone here has some more insight on the reason for throwing Exception,
> I'd love to hear.
> Thanks,
> -Flavio
> On 21 Nov 2016, at 13:21, Vadim <> wrote:
> Imesha,
>       I can't comment particularly this piece of code. The initial
> question was too general and I thought about QueueConsumer, for example, or
> other type of listener that is implemented by customer and executes
> customer code.
>      It might be some type of dependency for that function that could
> depend from customer code. If you want to go deeper - you can analyze
> source and check if there are such. May be there is no reason for that
> also. :)
> Vadim.
> On 2016-11-21 12:32, Imesha Sudasingha wrote:
> Hello Vadim,
> I didn't get your point. What I mean is, suppose we are going to create an
> ZNode. Consider the following example,
> curatorFrameworkInstance.create().forPath("/ZNode/path");
> In the above code, we have to surround with a try/catch since it is
> expected to throw an exception of type *Exception*. According to your
> explanation, how can this be a code written by me? What I am doing above is
> just executing the methods provided. Can you elaborate on that?
> -Imesha
> On 21 November 2016 at 13:45, Vadim <> wrote:
>> Hello Imesha,
>>        As user of curator, I guess this is because Curator suppose to
>> execute external code (like yours) and it does not know what type of the
>> exception it will throw in advance. If you define specific exception --
>> your code will be dependent on that and thus "hard dependency" arise. It
>> breaks DIP principle from SOLID (
>> /SOLID_(object-oriented_design)) that is not good.
>> Vadim.
>> On 2016-11-21 09:12, Imesha Sudasingha wrote:
>> Hi all,
>> I was curious on why most of the methods in *CuratorFramework* throw
>> exceptions of the type *Exception *which is the base class? In
>> Zookeeper, they have specific set of custom exceptions like
>> ZooKeeperException and so on. Do you have a specific reason for that?
>> Thanks in advance!
>> -Imesha
>> --
>> *Imesha Sudasingha*
>> Undergraduate of Department of Computer Science and  Engineering,
>> University of Moratuwa.
> --
> *Imesha Sudasingha*
> Undergraduate of Department of Computer Science and  Engineering,
> University of Moratuwa.

*Imesha Sudasingha*
Undergraduate of Department of Computer Science and  Engineering,
University of Moratuwa.
View in Linkedin <>

View raw message