Minor 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.