[
https://issues.apache.org/jira/browse/FLUME-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196736#comment-13196736
]
Peter Newcomb commented on FLUME-935:
-------------------------------------
I don't believe that I am actually "eating up" any exceptions, except in those
cases where I log secondary exceptions before rethrowing a prior one. I _am_
wrapping all non-RuntimeException exceptions with ChannelException before
rethrowing them, but only because the Channel interface does not allow throwing
other than RuntimeException exceptions (ChannelException is itself a
RuntimeException). I feel as you do that InterruptedException at least should
be a declared throwable of Channel methods, but it's not, yet.
-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
> 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
