curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Why do you throw exceptions of class Exception
Date Tue, 22 Nov 2016 15:14:54 GMT
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 <fpj@apache.org> 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 <vadim@ant.ee <mailto:vadim@ant.ee>>
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 <vadim@ant.ee <mailto:vadim@ant.ee>>
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.
> 


Mime
View raw message