On 11/04/2019 10:07 am, Toralf Lund wrote:
On 11/04/2019 09:39, Toralf Lund wrote:
On 10/04/2019 18:18, Gordon Sim wrote:
On 10/04/2019 10:10 am, Toralf Lund wrote:
Hi,
In one of my C++ "messaging" programs I sometimes use
qpid::Messaging::Session::checkError() as a way to "rethrow" (in as
somewhat loose sense) sender or receiver exceptions that were
already caught elsewhere. I notice that the exceptions I then get
are not quite the same as the original ones. I believe that with
some past QPid versions, the exception type would actually be
different. With more recent ones, it's the same, but it looks like
the type is the same, but the error message is not there - what()
returns an empty string.
Is that the expected behaviour? Are there any other cases where
there is no error description?
What type of error is this for? TransportFailure? I would expect the
what() message to be preserved.
It's a TransportFailure
catch(const qpid::types::Exception &error) {
std::cerr << "Exception \"" << error.what() << "\", address " <<
&error
<< ", type " << typeid(error).name() << "\n";
says
Exception "", address 0x2237e80, type
N4qpid9messaging16TransportFailureE
Original message is "Failed to connect (reconnect disabled)". I
provoke that error into occurring by suspending execution (kill -STOP
or Ctrl+Z), waiting for a while, then resuming.
I've now thrown together some of my code into a little test program -
see attachment. It wants an exchange and subject string as arguments,
and optionally "-b <broker>". Like I said, I'm using suspend + resume to
get connection issues. The below shows a typical test run, with output.
Note that I wait for a few seconds between "^Z" and "fg". Also, I don't
consistently get this result, there are cases where I don't get any of
the error messages, but a reconnect is still reported, or I see the 2nd
message but not the first.
If you sleep just before the updateConnection(), then when you wake the
test in that method will fail, but you will not have tried to use the
session/connection so no excweption would be thrown. I think that is as
expected?
For some reason, in the session the message from the original transport
error is not kept. I think this is because there is special handling of
the TransportFailure type and it wasn't deemed necessary.
It is easy to add that in, however it will not be the "Failed to connect
(reconnect disabled)" as that is not the original error that cause the
session to become invalid. It is thrown when considering whether to
reconnect or not.
It is a simple change to have the TransportFailure exception thrown by
Session::checkError() include the message from the original
TransportFailure that invalidated that session. Not sure if that is
actually that useful to you though.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
