[
https://issues.apache.org/jira/browse/GORA-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Ratnasekera updated GORA-180:
-----------------------------------
Fix Version/s: (was: 0.9)
1.0
> Better Exception handling post webservices API integration.
> -----------------------------------------------------------
>
> Key: GORA-180
> URL: https://issues.apache.org/jira/browse/GORA-180
> Project: Apache Gora
> Issue Type: Improvement
> Components: gora-core
> Affects Versions: 0.3
> Reporter: Lewis John McGibbney
> Assignee: Renato Javier Marroquín Mogrovejo
> Priority: Major
> Fix For: 1.0
>
>
> This is the result of some off list discussion with Ferdy. The suggestions are
> In some instances, we introduced catch-all Exception handling in order to
> address reviewer suggestion(s) prior to committing the patch. (To was to
> avoid having to declare "throws Exception" in the entire call stack). However
> a very important thing about this is to always rethrow the Exception in an
> exception that *is* declared in the method. Because IOException is a very
> common type of exception already in may call stacks, you do not have declare
> "throws IOException" everywhere.
> For example, the most crucial classes where this is currently not the case is
> in GoraRecordReader and GoraRecordWriter. Now it is possible have silent
> failures when reading or writing records. (Well not completely silent since
> you have logging in place, but it won't fail the tasks in a MapReduce
> environment! You really want to fail-fast tasks when there is something wrong
> in the core Gora code.)
> For example:
> GoraRecordWriter 72-74 --> In the catch-block, should have a statement:
> throw new IOException(e); //rethrow the Exception to let our calling stack
> know there is something seriously wrong
> GoraRecordReader 121-123 --> In the catch-block, should have a statement:
> throw new IOException(e);
> Actually there is almost never a good reason to dismiss Exception (by not
> rethrowing).
> This issues should encompass a review of the changes in line with the
> suggestions above and simply wrap and rethrow the places where this is
> currently not the case. Right now I do not know how deeply/widely rooted this
> problem is and how many areas improvements need to be made but we should be
> as thorough as possible here to trawl for as many instances as possible.
> Thanks Ferdy for the attention to detail... as always (anyone) please add
> your comments, opinions to this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
