[
https://issues.apache.org/jira/browse/QPID-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910171#comment-13910171
]
Robbie Gemmell commented on QPID-5551:
--------------------------------------
As you already know, some 0-9 python tests are failing due to changing some
channel exceptions to connection exceptions.
{quote}
First one was simply because no checked exceptions are being thrown now...
generally catching Runtimes is bad... I'm not totally sure I buy the rationale
in the original comment in that the first exception might (however unlikely) be
unrelated to the second... the first exception may only have been a connection
scoped exception, in which it would be OK to rollback the transaction and then
continue. However if the rollback fails that is a server scoped exception and
should bring down the server. Realistically if anything is lost it is likely to
be something similar (store related) to the second exception... and all the
store exception should now be logged.
{quote}
Fair enough, just checking :)
{quote}
Third one... I'll try to restore something of the functionality... basically
catching and rethrowing runtimes... though I wonder if we should not
immediately exit on ServerScoped exceptions
{quote}
I was really only interested in avoiding the things that made us make those
changes originally. I'd be fine with the additional change...though if we did
the question then might become, why do we ever throw them instead of just
exiting, or if we do should they be Errors instead so that they are less likely
to get caught in the first place?
> [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: Rob Godfrey
> 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]
