Is your feature request related to a problem? Please describe.
When you hit an OSError, unless you have debug log level tracing enabled your client code may wind up with a bare OSError with little context for what bus was responsible. When more than one bus is involved in your system you're left to disambiguate with some custom code of one's own.
Describe the solution you'd like
I'd like the OSError to have a note added to it with the necessary context to identify what bus channel was involved with the error. A perfect solution would be to augment the logic defined here
|
def bind_socket(sock: socket.socket, channel: str = "can0") -> None: |
|
""" |
|
Binds the given socket to the given interface. |
|
|
|
:param sock: |
|
The socket to be bound |
|
:param channel: |
|
The channel / interface to bind to |
|
:raises OSError: |
|
If the specified interface isn't found. |
|
""" |
|
log.debug("Binding socket to channel=%s", channel) |
|
sock.bind((channel,)) |
|
log.debug("Bound socket.") |
and replace it with
601c601,607
< sock.bind((channel,))
---
> try:
> sock.bind((channel,))
> except OSError as exc:
> exc_msg = f"Error binding socketcan bus at {channel=}"
> log.exception(exc_msg)
> exc.add_note(exc_msg)
> raise
604d609
<
Describe alternatives you've considered
none
Additional context
Consider any other areas of the python-can codebase that similarly raise naked python errors without context. Those should also benefit by injecting notes with the surrounding context that was being attempted.
Is your feature request related to a problem? Please describe.
When you hit an OSError, unless you have debug log level tracing enabled your client code may wind up with a bare OSError with little context for what bus was responsible. When more than one bus is involved in your system you're left to disambiguate with some custom code of one's own.
Describe the solution you'd like
I'd like the OSError to have a note added to it with the necessary context to identify what bus channel was involved with the error. A perfect solution would be to augment the logic defined here
python-can/can/interfaces/socketcan/socketcan.py
Lines 589 to 602 in b4f82ab
and replace it with
Describe alternatives you've considered
none
Additional context
Consider any other areas of the python-can codebase that similarly raise naked python errors without context. Those should also benefit by injecting notes with the surrounding context that was being attempted.