Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changed AddDataChangeCallback to mirror python-opcua implementation #293

Closed
wants to merge 2 commits into from

Conversation

Magnulas
Copy link

The AddDataChangeCallback function was changed to return a OPC UA status code to indicate if adding the callback was successful. The exception that was thrown from AddDataChangeCallback when adding a callback failed triggered a goodbye message to be sent to the connecting client when they were attempting to create a monitored item. This fix should make connecting clients receive the proper OPC UA status code instead.

Magnus Raunio added 2 commits December 19, 2017 14:31
… when a non-existing node or attribute were added as a monitored item. The AddDataChangeCallback was changed to mirror the python-opcua implementation.
@ralf1070
Copy link
Contributor

At most places freeOpcUa indicates errors by throwing exceptions. This is done for a reason as you are able to separate error handling from normal program flow. You don't need to handle an error at the same place as you handle a regular result of a function. And - for what I think - this is the usual way to indicate errors in C++. If you need further information about the thrown error then subclass "std::runtime_error" and add the information you need and throw such an instance.

From my point of view returning status codes is good old K&R C style and should be avoided where ever possible. To create temporary instances of pairs of return values and status codes is even worse. It is inefficient and confusing ... just my 2 cents.

@Magnulas
Copy link
Author

If preferred I'll submit a pull request where AddDataChangeCallback throws a exception wrapping the appropriate status code and let CreateMonitoredItem handle the exception, setting the status code for the request based on what the exception contained.

@ralf1070
Copy link
Contributor

From my point of view this would be the better solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants