-
Notifications
You must be signed in to change notification settings - Fork 74
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
Provide more meaningful output on error #291
Comments
@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 |
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:
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. |
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
|
Identifying line numbers related to syntax issues is probably best as a feature request in the launch repo; certainly a feature worth adding 👍 |
Here's a relevant ticket: ros2/launch#412 |
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 😄
launch
API is invalidThe text was updated successfully, but these errors were encountered: