[
https://issues.apache.org/jira/browse/QPID-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-5551:
------------------------------
Description:
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.
was:
Currently lots of methods throw AMQException which was original 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.
> [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]
