[
https://issues.apache.org/jira/browse/QPID-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908597#comment-13908597
]
Robbie Gemmell commented on QPID-5551:
--------------------------------------
Looks mostly good, some niggles:
- The potential change we discussed from a ConnectionException to
ChannelException due to the consumer ACL check.
- There are a couple cases where exceptions were deliberately being caught and
not rethrown, whereas they now wont be caught. Deliberate change?
{noformat}
@@ -261,17 +236,7 @@ public class AutoCommitTransaction implements
ServerTransaction
{
if (txn != null)
{
- try
- {
- txn.abortTran();
- }
- catch (AMQStoreException e)
- {
- _logger.error("Abort transaction failed", e);
- // Deliberate decision not to re-throw this exception.
Rationale: we can only reach here if a previous
- // TransactionLog method has ended in Exception. If we were
to re-throw here, we would prevent
- // our caller from receiving the original exception (which is
likely to be more revealing of the underlying error
- }
+ txn.abortTran();
}
if (postTransactionAction != null)
{
{noformat}
- Some newly commented out code:
{noformat}
@@ -82,17 +82,22 @@ public class ExchangeRecoverer extends
AbstractDurableConfiguredObjectRecoverer<
_exchange = _exchangeFactory.restoreExchange(id,
exchangeName, exchangeType, autoDelete);
_exchangeRegistry.registerExchange(_exchange);
}
- }
+ }/*
catch (AMQException e)
{
throw new RuntimeException("Error recovering exchange uuid " +
id + " name " + exchangeName, e);
- }
+ }*/
{noformat}
- Not sure about this bit. We only just recently changed it to do what it was
doing, because if it threw an exception there it could fail to indicate to any
other subsequent 'innocent' sessions that they should complete their deferred
work.
{noformat}
@@ -314,34 +314,14 @@ public class AMQProtocolEngine implements
ServerProtocolEngine, AMQProtocolSessi
}
}
- private void receivedComplete() throws AMQException
+ private void receivedComplete()
{
- Exception exception = null;
for (AMQChannel channel : _channelsForCurrentMessage)
{
- try
- {
- channel.receivedComplete();
- }
- catch(Exception exceptionForThisChannel)
- {
- if(exception == null)
- {
- exception = exceptionForThisChannel;
- }
- _logger.error("Error informing channel that receiving is
complete. Channel: " + channel, exceptionForThisChannel)
- }
+ channel.receivedComplete();
}
_channelsForCurrentMessage.clear();
-
- if(exception != null)
- {
- throw new AMQException(
- AMQConstant.INTERNAL_ERROR,
- "Error informing channel that receiving is complete: " +
exception.getMessage(),
- exception);
- }
}
/**
{noformat}
> [Java Broker] Improve use of exceptions throughout the broker
> -------------------------------------------------------------
>
> Key: QPID-5551
> URL: https://issues.apache.org/jira/browse/QPID-5551
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Priority: Minor
>
> Currently lots of methods throw AMQException which was originally intended to
> represent connection and channel closure reasons.
> Now these are actually only generated from the 0-8 protocol plugin, however
> the same base class is used for security exceptions (AMQSecurityException)
> and also for errors encountered in the store (via AMQInternalException).
> Where there is no obvious way to deal with an exception it is either being
> directly rethrown, or wrapped in a runtime exception or similar.
> We should remove cases of methods throwing AMQException when there is no path
> through which they can actually throw that exception. We should then change
> the use of exceptions in the broker to differentiate between those which we
> expect to handle in some way (like security exceptions) versus those which
> will only be handled in a coarse manner (exceptions that can only result in
> the closure of a connection, or even of the entire virtual host or broker).
> For the latter two cases I propose we introduce new RuntimeException classes
> for ConnectionScopedRuntimeException, VirtualHostScopedRuntimeException and
> BrokerScopedRuntimeException.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
