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 
it down:

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

Reply via email to