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] <mailto:[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] <mailto:[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)) >>> <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. >
