You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Darren Shepherd <da...@gmail.com> on 2013/09/27 20:07:00 UTC

NetworkElement and other *ServiceProviders often have useless return values

On NetworkElement and many other *ServiceProvider interfaces (ie
DhcpServiceProvider), the return value for the methods are a boolean,
but those booleans are never checked.  I would like to clean up all
these interfaces and put the majority of the methods to return "void."
 Would there be any objection to this?  I find it quite confusing when
implementing an interface when I have to look at calling code to
determine if I should return false or throw an exception in some case.

Cleaning this up would mean I'd have to update all the implementations
of the interfaces.

Darren

RE: NetworkElement and other *ServiceProviders often have useless return values

Posted by Alex Huang <Al...@citrix.com>.
Shouldn't be a problem.  They were Boolean previously to mean this networkelement does not know how to apply the rule, move on to the next one because previously it was really more like a broadcast to all networkelements.  Whichever networkelment believes they should apply the rule, then applies.  Now, it is more prescriptive as the service providers are actually specified by the admin when they create the zone so the Boolean is no longer needed.  I doubt it's checked anywhere.

--Alex

> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
> Sent: Friday, September 27, 2013 11:07 AM
> To: dev@cloudstack.apache.org; Chiradeep Vittal; Alex Huang
> Subject: NetworkElement and other *ServiceProviders often have useless
> return values
> 
> On NetworkElement and many other *ServiceProvider interfaces (ie
> DhcpServiceProvider), the return value for the methods are a boolean, but
> those booleans are never checked.  I would like to clean up all these
> interfaces and put the majority of the methods to return "void."
>  Would there be any objection to this?  I find it quite confusing when
> implementing an interface when I have to look at calling code to determine if
> I should return false or throw an exception in some case.
> 
> Cleaning this up would mean I'd have to update all the implementations of
> the interfaces.
> 
> Darren