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

Gracefully handle errors when binding SocketCAN fails #1771

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

acolomb
Copy link
Contributor

@acolomb acolomb commented Apr 24, 2024

The parent class BusABC expects to be shutdown properly, checked via its self._is_shutdown flag during object deletion. But that flag is only set when the base class' shutdown() is called, which doesn't happen if instantiation of the concrete class failed in can.Bus(). So there is no way to avoid the warning message "SocketcanBus was not properly shut down" if the constructor raised an exception.

This change addresses that issue for the SocketCAN interface, by catching an OSError exception in bind_socket(), logging it, and calling self.shutdown() before re-raising the exception.

There might be a better approach which also works for the other backends? The flag could be initialized to True and only reset to False when the BusABC constructor runs (which happens last in derived classes)?

Thus leaving this as a draft for further discussion.

The parent class BusABC expects to be shutdown properly, checked via
its self._is_shutdown flag during object deletion.  But that flag is
only set when the base class shutdown() is called, which doesn't
happen if instantiation of the concrete class failed in can.Bus().  So
there is no way to avoid the warning message "SocketcanBus was not
properly shut down" if the constructor raised an exception.

This change addresses that issue for the SocketCAN interface, by
catching an OSError exception in bind_socket(), logging it, and
calling self.shutdown().
@acolomb
Copy link
Contributor Author

acolomb commented Apr 25, 2024

The alternative approach is now proposed in #1774. This PR could still be useful in addition, to have a proper error log message. If that is desired...

Copy link
Owner

@hardbyte hardbyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to merge this too - perhaps remove the comment and the shutdown call

@acolomb
Copy link
Contributor Author

acolomb commented Apr 30, 2024

Adjusted as requested. Thanks for your consideration.

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.

None yet

2 participants