mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: question about condition checking in Mahout
Date Tue, 10 Aug 2010 17:18:59 GMT
Is Guava already a dependency somehow? maybe so, I never looked.

If so I find this a decent idea. It's a big undertaking to convert all
arg checking, and perhaps tighten up argument checking in other
places. You'd be welcome to do so and file a JIRA with a patch.

My concern would be a half-way patch. Then we'd be in a more
inconsistent state and that's not good.

On Tue, Aug 10, 2010 at 8:17 AM, Eugen Paraschiv <hanriseldon@gmail.com> wrote:
> Hi,
> We are starting to use Mahout for a recommendation project at work - it has
> been a good experience so far. We went through the integration process
> without any notable hurdles, and we’ve kept some notes along the way. I will
> start with a general observation and follow up with some more in the future,
> so that we may get some feedback from the community and help with patches
> where needed.
> One thing I’ve noticed is that there doesn’t seem to be a consistent way of
> validating method arguments.
> There is a Preconditions utility class in *G*uava (the formed Google
> Collections) for checking various stuff such as not nulls or boolean
> conditions:
> Preconditions.checkNotNull( object ); or
> Preconditions.checkState(  expression, “errorMessage” );
> This can be used instead of manual checks such as:
> if( delimiterTwo < 0 ){
>      throw new IllegalArgumentException( "Bad line: " + line );
> }
> This kind of checking has many advantages:
> - it ensures a consistent exception logic, making sure you always throw the
> exact same exceptions in speciffic situations (such as checking an argument)
> - it makes the code more readable and reduces the cognitive load for a
> client going through it
> - it keeps the method at a single level of abstraction - throwing an
> exception when a parameter is invalid is a low level of abstraction whereas
> the following logic is a higher level of abstraction - the two should not be
> mixed
> Seeing how *Guava* is already a dependency, it makes sense to use it to it
> full potential. Reducing the cognitive load of the code may not be that
> relevant in some cases, but it is very important when dealing with very long
> methods such as *FileDataModel* - *processLine*.
> Is this a direction that makes sense for Mahout? If so, how should I go
> forward with helping - is the standard route of opening JIRA issues and
> submitting patches OK?
> Thanks.
> Eugen.
>

Mime
View raw message