I get your point. Thanks for the explanation! -Imesha
On 23 November 2016 at 07:05, Jordan Zimmerman <[email protected]> wrote: > I'm not defending the decision. Someone asked why. I'd like to move to not > using checked exceptions at all ala Jersey 2.0 > > ==================== > Jordan Zimmerman > > On Nov 22, 2016, at 8:05 PM, Imesha Sudasingha <[email protected]> > wrote: > > 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> > > -- *Imesha Sudasingha* Undergraduate of Department of Computer Science and Engineering, University of Moratuwa. +94717086160 View in Linkedin <https://lk.linkedin.com/in/imeshasudasingha>
