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

Incorrect Exception Message in send_request() of client.py #253

Open
6reend0g opened this issue Dec 5, 2024 · 5 comments
Open

Incorrect Exception Message in send_request() of client.py #253

6reend0g opened this issue Dec 5, 2024 · 5 comments

Comments

@6reend0g
Copy link

6reend0g commented Dec 5, 2024

When reviewing the client.py code at line 2216, I noticed the following:

raise TimeoutException('**Did** not receive response in time. %s time has expired (timeout=%.3f sec)' %)

The term "Did" seems to be a typo or a misrepresentation. Based on the context, "Sid" might be more appropriate. However, to make the message more accurate and universally applicable, I suggest replacing it with "Service."

Here’s why:
This exception is raised whenever a diagnostic request times out, regardless of the specific Sid (e.g., 22 or 2E services, which are related to DIDs). The term "Service" would better reflect that the timeout applies broadly to any diagnostic service, not just DID-related ones.

@pylessard
Copy link
Owner

Did is the verb "to do", past tense

@6reend0g
Copy link
Author

6reend0g commented Dec 5, 2024

Fine, this is a little bit misleading for me . XD

@pylessard
Copy link
Owner

I can update the message to use a more functional language, something like "Failed to receive a response in time". Does that seems better to you?

@6reend0g
Copy link
Author

6reend0g commented Dec 5, 2024

I prefer this expression, 'Failed' makes it seem more like error handling.
By the way, there is one more question want to bother you.when using the isotp as conn of a Client, It`s hard to send messages via physical address and functional address using the same Client, whether you have a better method to solve this,or maybe there is a library better than isotp when using DoCAN.

@6reend0g
Copy link
Author

6reend0g commented Dec 6, 2024

I prefer this expression, 'Failed' makes it seem more like error handling. By the way, there is one more question want to bother you. when using the isotp as conn of a Client, it`s hard to send messages via physical address and functional address using the same Client, whether you have a better method to solve this, or maybe there is a library better than isotp when using DoCAN.

I figured it out: I had created two buses for each isotp stack in my previous program. This might have caused a preemption issue between the two buses. When I created only one bus to handle both isotp stacks, the problem was resolved.

In the end, thank you for your reply. Have a good day.

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

No branches or pull requests

2 participants