mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Committing was Re: [jira] Commented: (MAHOUT-10) Replace fall-through exception handlers with propagated unchecked exception.
Date Sun, 09 Mar 2008 13:42:06 GMT
Definitely.  You have full powers :-)

General rule of thumb is to use your judgment.  If it is a significant  
change, then ask around and/or say something like "I plan on  
committing in 2 days or something like that."  Minor changes can be  
committed sooner.  Both major and minor should have a JIRA issue  
associated.  Typos and small doc changes don't, IMO.

I usually do my commit messages as something like "MAHOUT-X: blah,  
blah, blah".  If you use this format, then JIRA can automatically  
extract the revision from SVN and display it under the Subversion  
section of that issue.  Then, when I commit, I also note, when  
resolving the issue, what revision I committed on.


On Mar 9, 2008, at 7:09 AM, Dawid Weiss (JIRA) wrote:

>    [

> #action_12576749 ]
> Dawid Weiss commented on MAHOUT-10:
> -----------------------------------
> Hey guys. What's our committing policy? Can I commit issues nodoby  
> objected to for some time? Especially if they are trivial, like this  
> one?
>> Replace fall-through exception handlers with propagated unchecked  
>> exception.
>> ----------------------------------------------------------------------------
>>                Key: MAHOUT-10
>>                URL:
>>            Project: Mahout
>>         Issue Type: Improvement
>>         Components: Clustering
>>   Affects Versions: 0.1
>>           Reporter: Dawid Weiss
>>           Assignee: Dawid Weiss
>>           Priority: Minor
>>        Attachments: mah-10.patch
>> I am doing a belated code review. There certain issues that I would  
>> like to change, for example fall-through exception handlers like  
>> this one:
>>    try {
>>      Class cl = Class.forName(job.get(DISTANCE_MEASURE_KEY));
>>      measure = (DistanceMeasure) cl.newInstance();
>>      measure.configure(job);
>>    } catch (Exception e) {
>>      e.printStackTrace();
>>    }
>> This prints the stack trace of an exception to the console, but  
>> continues thread's execution after the catch clause. Since distance  
>> measure key is required, this makes little sense. A runtime  
>> exception should be thrown -- this stops the job and causes a full  
>> stack trace to be displayed anyway (with the nested exception's  
>> message).
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

Grant Ingersoll
Next Training: April 7, 2008 at ApacheCon Europe in Amsterdam

Lucene Helpful Hints:

View raw message