Skip to content

Conversation

@saikishor
Copy link
Member

No description provided.

@codecov
Copy link

codecov bot commented Nov 12, 2025

Codecov Report

❌ Patch coverage is 28.07018% with 41 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.43%. Comparing base (fc77935) to head (c83f28a).

Files with missing lines Patch % Lines
hardware_interface/src/resource_manager.cpp 37.50% 25 Missing ⚠️
controller_manager/src/controller_manager.cpp 5.88% 16 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2807      +/-   ##
==========================================
- Coverage   89.61%   89.43%   -0.19%     
==========================================
  Files         152      152              
  Lines       17774    17820      +46     
  Branches     1460     1460              
==========================================
+ Hits        15929    15937       +8     
- Misses       1253     1292      +39     
+ Partials      592      591       -1     
Flag Coverage Δ
unittests 89.43% <28.07%> (-0.19%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
...rdware_interface/types/resource_manager_params.hpp 100.00% <ø> (ø)
controller_manager/src/controller_manager.cpp 76.57% <5.88%> (-0.47%) ⬇️
hardware_interface/src/resource_manager.cpp 78.12% <37.50%> (-1.71%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Member

@destogl destogl left a comment

Choose a reason for hiding this comment

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

What is the main idea behind this? We are adding handling of failure on HW exception. But I don't know why we should do this just per-default? I agree that should never crash but not like this, instead by making sure we manage the all cases.

@saikishor
Copy link
Member Author

saikishor commented Nov 12, 2025

What is the main idea behind this? We are adding handling of failure on HW exception. But I don't know why we should do this just per-default? I agree that should never crash but not like this, instead by making sure we manage the all cases.

Recently, we are coming across the raised exceptions from third party libraries etc and the problem is if they don't have a proper exception message it is very hard to debug. By crashing, it prints the stack trace and with this we can find the issue easily.

For instance, we have been having an issue last couple of weeks and we spent lot of time on it and today just removing the exception catching and making it to crash with the stack trace it print, we were able to pin point the issue in less than 5 min. If this kind of issue happens in future, it is better to launch it with this parameter and you could find the issue right away. It is more for the debugging purposes.

Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

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

This is great. Let's just add a description in the debugging section to the docs.

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.

3 participants