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 <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 (https://en.wikipedia.org/wiki >> /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. +94717086160 View in Linkedin <https://lk.linkedin.com/in/imeshasudasingha>
