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
