mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eugen Paraschiv <hanrisel...@gmail.com>
Subject question about condition checking in Mahout
Date Tue, 10 Aug 2010 13:56:35 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message