Alan Conway commented on PROTON-1095:
The connection_engine took an ad-hoc approach to error handling because the
handler API was inadequate. Andrew has fixed that inadequacy, so it makes sense
to apply the fix across the board, not just for the container. It would be nice
to provide users of 0.12 with a consistent error-handling experience. To break
Added condition::empty() - Andrew specifically noted operator! as a discussion
point. I added empty() as part of that discussion. All the standard "container"
types in C++ have an empty() function to test for "nothing there". IMO the
condition is a container of error information so this is an idiomatic way to
test it. I'm fine with having operator! as well although it is likely to be
more controversial :)
Removed process_nothrow: The only reason for this was to deal with the issue of
users who prefer/dislike exceptions. Andrews changes give the user perfect
control of this so it is unnecessary. connection_engine::process() throws if
and only if the user handler throws, exactly like container::run()
Removed disconnect: No longer needed because simply closing the underlying
transport will cause the handler to receive transport_error and allow it to
decide whether or not to throw, exactly as for a container handler. Lovely!
Return pair<size_t, bool> from io_read rather than throwing on stream close.
This is a trivial improvement to an heretofore unreleased and unused
integration API that is exception related. It is not strictly required but
seems like it would be good to make the change earlier rather than later. Mea
culpa for sneaking this in, I'll have myself flogged.
Phew, I really did not expect this to be controversial!!
> Error handling
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
> The C++ binding needs a disciplined and effective way to handle protocol (and
> transport) errors.
> Currently the API has some error events, however if they are not handled the
> program will just hang - it would be better in this case to throw an
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a
> connection/session/link - there should be some straightforward way to
> indicate the error to your peer.
This message was sent by Atlassian JIRA