On 11/04/2019 12:53, Gordon Sim wrote:
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?
I believe it is.
Also, I suspect Session::checkError() might throw the "empty"
TransportFailure even if no send or receive has been attempted (yet), so
getting only the 2nd messages might just mean I happened to
interrupt/restart after "publish" but before "checkError".
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.
Fair enough.
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.
No, it might not make a whole lot of difference. As long as I know
what's going on, I'm quite all right, really.
Thanks.
- Toralf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
