[
https://issues.apache.org/jira/browse/FLUME-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197644#comment-13197644
]
Peter Newcomb commented on FLUME-935:
-------------------------------------
Whew! I thought that was odd. Glad you figured it out.
I think it would be common at least to throw IOException and
InterruptedException. I widened it to Exception mostly because I didn't think
the framework could meaningfully further constrain it without making
assumptions about the range of specific implementations. As per your earlier
comment, I think that special handling of InterruptedException does make sense
(unless the Channel interface is changed to throw it), but it seems to me that
no matter what other subtype of Exception might be thrown by an doXYZ
implementation, it would always need to be wrapped with a ChannelException
unless we make the Channel interface itself throw Exception.
Making the abstract class do this wrapping generically is mostly a convenience,
to be sure--but the point of the abstract class itself is to simplify the
concrete implementations of the interface(s), so I would claim that allowing
the doXYZ methods to throw Exception and then generically wrapping them with
ChannelException when necessary _is_ and appropriate thing for the abstract
class to do.
-peter
> Create abstract implementations of basic channel/transaction semantics
> ----------------------------------------------------------------------
>
> Key: FLUME-935
> URL: https://issues.apache.org/jira/browse/FLUME-935
> Project: Flume
> Issue Type: Improvement
> Components: Channel
> Affects Versions: v1.0.0
> Reporter: Peter Newcomb
> Assignee: Peter Newcomb
> Priority: Minor
> Fix For: v1.1.0
>
>
> Correctly executing or checking the state transitions for channels and
> transactions is nontrivial. It would be helpful to have a correct
> implementation of each that can be used either directly or as a reference
> when creating new channels or clients of channels.
> Specifically, on the client side it would be nice to package the try {
> begin() ... commit() } catch { rollback() } finally { close() } code, with
> all the appropriate exception propagation and logging code, so that it need
> not be repeated constantly.
> On the channel side, it'd be nice to have a packaged implementation of the
> implied ThreadLocal semantics of the Transaction class, along with
> Preconditions checking to make sure that clients follow the try { begin() ...
> commit() } catch { rollback() } finally { close() } pattern.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
