Provide more meaningful output on error

[SteveMacenski]

Feature request

Feature description

When launch cannot find a package, a launch file does not exist, a node doesn't exist, or generally speaking something goes wrong, the traceback provided really doesn't help in debugging the issue. I would really like these to be caught and categorized so that users receive a meaningful error message back about what they're doing wrong to be able to fix, ideally with the offending line.

I'm finding it quite difficult when building new launch files and errors occur to figure out what's wrong. The terminal gets filled with internal launch tracebacks that infrequently help in diagnosing the underlying issue. Especially for common errors, we should have common error messages that tells people why it failed to execute and suppress the traceback. Surely this is an uphill battle to cover all situations, but if we simply cover the top 10, I think that would be a huge quality of life improvement. Personally speaking, I probably spend 3-4x as much time debugging launch files when building a new somewhat complex piece of software than a complimentary bug in C++, so I think there's some room for at least incremental improvement :smile:

• Package doesn't exist on system
• Launch file or node doesn't exist on system
• Python syntax errors
• Field given to a launch API is invalid

[SteveMacenski]

@hidmic I know this is probably low priority, but is this on anyone's radar for an upcoming release? This is a big quality of life issue in trying to debug modest robotic systems

[jacobperron]

I'm not aware of anyone planning to tackle this issue, though I'm happy to review proposals if anyone in the community would like to work on it.

IIUC, errors are communicated via exceptions that launch catches and logs. I guess there are situations where the errors are not being caught and we're getting undesired tracebacks.

For instance, if I launch a node action for a package that doesn't exist, the message looks okay to me:

jacob@warner ~/tmp> ros2 launch talker.launch.py        
[INFO] [launch]: All log files can be found below /home/jacob/.ros/log/2022-05-31-14-41-11-720542-warner-19000
[INFO] [launch]: Default logging verbosity is set to INFO
[ERROR] [launch]: Caught exception in launch (see debug for traceback): "package 'foo' not found, searching: ['/opt/ros/rolling']"

Of course it would be better if it gave us a file and line number, but that might be something that needs to be added upstream in launch (I'm not sure). If there are particular messages that are cryptic, or a category of error that is causing a traceback, we can probably improve those on a case-by-case basis.

[SteveMacenski]

An example is syntactical errors, they result in not super helpful things like below, which in no place give you the line number or name of the offending object within the actual luanch file itself (only line numbers and lines of internal launch systems). This is an example a colleague sent me to help debug because they couldn't figure out what went wrong (ended up being a DeclareLaunchArgument vs LaunchConfiguration issue)

Even just giving me a line number or object that is problematic could help alot when there's 1 error in a massive launch file

[INFO] [launch]: All log files can be found below /home/XYZ/.ros/log/2022-05-24-15-03-11-094353-tb07-286055
[INFO] [launch]: Default logging verbosity is set to INFO
Task exception was never retrieved
future: <Task finished name='Task-2' coro=<LaunchService._process_one_event() done, defined at /opt/ros/foxy/lib/python3.8/site-packages/launch/launch_service.py:226> exception=TypeError("'DeclareLaunchArgument' object is not iterable")>
Traceback (most recent call last):
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/launch_service.py", line 228, in _process_one_event
    await self.__process_event(next_event)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/launch_service.py", line 248, in __process_event
    visit_all_entities_and_collect_futures(entity, self.__context))
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/utilities/visit_all_entities_and_collect_futures_impl.py", line 45, in visit_all_entities_and_collect_futures
    futures_to_return += visit_all_entities_and_collect_futures(sub_entity, context)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/utilities/visit_all_entities_and_collect_futures_impl.py", line 45, in visit_all_entities_and_collect_futures
    futures_to_return += visit_all_entities_and_collect_futures(sub_entity, context)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/utilities/visit_all_entities_and_collect_futures_impl.py", line 45, in visit_all_entities_and_collect_futures
    futures_to_return += visit_all_entities_and_collect_futures(sub_entity, context)
  [Previous line repeated 1 more time]
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/utilities/visit_all_entities_and_collect_futures_impl.py", line 38, in visit_all_entities_and_collect_futures
    sub_entities = entity.visit(context)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/action.py", line 108, in visit
    return self.execute(context)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/actions/include_launch_description.py", line 159, in execute
    set_launch_configuration_actions.append(SetLaunchConfiguration(name, value))
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/actions/set_launch_configuration.py", line 49, in __init__
    self.__value = normalize_to_list_of_substitutions(value)
  File "/opt/ros/foxy/lib/python3.8/site-packages/launch/utilities/normalize_to_list_of_substitutions_impl.py", line 44, in normalize_to_list_of_substitutions
    return [normalize(y) for y in cast(Iterable, subs)]
TypeError: 'DeclareLaunchArgument' object is not iterable

[jacobperron]

Identifying line numbers related to syntax issues is probably best as a feature request in the launch repo; certainly a feature worth adding :+1:

[jacobperron]

Here's a relevant ticket: https://github.com/ros2/launch/issues/412 I suppose the issue could extend to Python launch files as well.