[hardware_interface_testing] Add tests for hardware components exception handling

[shlok-mehndiratta]

Summary

This PR addresses Issue #1530 by providing automated verification for the hardware exception-handling logic in ResourceManager. The goal is to ensure that plugin-level failures are handled predictably and that the core system remains stable when plugins encounter errors.

Approach & Verification

Targeted Verification Suite

To resolve the task, I have added a series of automated tests to the hardware_interface_testing suite. I followed the maintainer suggestion of using URDF parameters (throw_on_*) to trigger failure points deterministically within existing test components. This allows us to verify:

• Graceful recovery during lifecycle transitions (e.g., on_configure, on_activate).
• Stability of the read and write cyclic loops when plugins throw exceptions.
• Proper handling of unknown exceptions (catch(...)) to prevent silent crashes.

Surgical Refinements for Consistency

While adding these tests, I identified and addressed a few areas for better consistency:

• Interface Imports: Refined import_state_interfaces to align its exception handling with the established pattern for command interfaces.
• Error Context: Standardized how exceptions are logged to ensure that hardware failures provide clear context for debugging.

Review Request

I have aimed to keep these changes surgical and scoped strictly to the requirements of the issue. The new tests provide a baseline to ensure that future updates to hardware plugins or the resource manager do not regress in their error handling.

All 88 tests in the package (57 existing + 31 new/refined) are passing locally. I would appreciate your feedback on the implementation and testing strategy, particularly regarding the failure injection points in the mock components.

---

Verified locally with colcon test (Screenshot attached below).

[codecov]

Codecov Report

❌ Patch coverage is 97.63593% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.62%. Comparing base (35c8db9) to head (4d353ce).

Files with missing lines	Patch %	Lines
...rface_testing/test/test_components/test_sensor.cpp	87.50%	3 Missing and 1 partial ⚠️
...erface_testing/test/test_rm_exception_handling.cpp	98.68%	2 Missing and 2 partials ⚠️
...ace_testing/test/test_components/test_actuator.cpp	97.22%	0 Missing and 1 partial ⚠️
...rface_testing/test/test_components/test_system.cpp	97.50%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3228      +/-   ##
==========================================
+ Coverage   89.06%   89.62%   +0.55%     
==========================================
  Files         160      161       +1     
  Lines       19751    20170     +419     
  Branches     1597     1602       +5     
==========================================
+ Hits        17592    18077     +485     
+ Misses       1493     1428      -65     
+ Partials      666      665       -1     

Flag	Coverage Δ
unittests	89.62% <97.63%> (+0.55%)	⬆️

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

Files with missing lines	Coverage Δ
hardware_interface/src/resource_manager.cpp	85.40% <100.00%> (+6.93%)	⬆️
...ace_testing/test/test_components/test_actuator.cpp	90.90% <97.22%> (+2.36%)	⬆️
...rface_testing/test/test_components/test_system.cpp	88.05% <97.50%> (+4.01%)	⬆️
...rface_testing/test/test_components/test_sensor.cpp	77.35% <87.50%> (+15.45%)	⬆️
...erface_testing/test/test_rm_exception_handling.cpp	98.68% <98.68%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shlok-mehndiratta]

@christophfroehlich @saikishor
This PR is now fully synchronized with the latest master and the implementation is finalized. Moving this to "Ready for Review".
I would appreciate your feedback on the implementation and testing strategy.

[saikishor]

Interesting approach. Changes LGTM, however, I'm questioning myself if we need to inject it into all 3 types of components?. Because this is something crucial if one thing works, it is same for the other two that's why.

@ros-controls/ros-controls-pmc what do you think about it?

[shlok-mehndiratta]

Interesting approach. Changes LGTM, however, I'm questioning myself if we need to inject it into all 3 types of components?. Because this is something crucial if one thing works, it is same for the other two that's why.

@ros-controls/ros-controls-pmc what do you think about it?

@saikishor, thank you for the feedback.

That’s a very valid point regarding the redundancy. You’re right that the underlying handler logic in ResourceManager is designed to be DRY and shared across component types.

My reasoning for including failure injection in all three types (Actuators, Sensors, and Systems) was primarily to achieve the high coverage targets for the ResourceManager itself. In methods like read(), write(), and set_component_state(), the ResourceManager uses separate iteration loops and call sites for each vector. I found that if I only tested one type (like Systems), the error-handling paths and specific vector-cleanups for Actuators and Sensors remained marked as "uncovered" in the coverage report.

Since the goal of this task was specifically to harden the exception coverage, I opted for this more exhaustive approach to ensure no "dark spots" were left in the RM implementation.

I'm happy to consolidate these tests into a single component type if you'd prefer a more concise test suite over targeting absolute coverage for every vector.