Avoid tracebacks for "expected" errors?

[bit-pirate]

For cases like a stop request for a not running capability or a start request for unknown capabilities/provides, once currently gets a ros error plus a traceback. Can this traceback be avoided? It adds a lot of output, where as the ros error gives enough information already.

[INFO] [WallTime: 1378857082.898716] Request to stop capability 'minimal_pkg/Minimal'
Traceback (most recent call last):
  File "/opt/ros/hydro/lib/python2.7/dist-packages/rospy/impl/tcpros_service.py", line 619, in _handle_request
    response = convert_return_to_response(self.handler(request), self.response_class)
  File "/opt/kobuki_workspace/catkin_ws/src/capabilities/src/capabilities/server.py", line 477, in handle_stop_capability
    self.__stop_capability(capability)
  File "/opt/kobuki_workspace/catkin_ws/src/capabilities/src/capabilities/server.py", line 383, in __stop_capability
    self.__launch_manager.stop_capability_provider(capability.pid)
  File "/opt/kobuki_workspace/catkin_ws/src/capabilities/src/capabilities/launch_manager.py", line 120, in stop_capability_provider
    self.__stop_by_pid(pid)
  File "/opt/kobuki_workspace/catkin_ws/src/capabilities/src/capabilities/launch_manager.py", line 107, in __stop_by_pid
    raise RuntimeError("No running launch file with PID of '{0}'".format(pid))
RuntimeError: No running launch file with PID of '5651'
[ERROR] [WallTime: 1378857082.899984] Error processing request: No running launch file with PID of '5651

[wjwwood]

This is only on the server side, so it's not what I would consider user facing. To me, at least, it is useful for understanding where an issue is coming from. I left it there on purpose, but I can take it out.

I'll try and add a flag for toggling this information on and make it off by default.

[bit-pirate]

True, once people get familiar with the app manager, most users probably won't interface much with the capability server any more. However capability/capability provider developers will often use it to test and verify their implementations. And probably there will always be users, who won't use the app manager and just the capabilities. So in order to avoid those people getting confused or annoyed by the traceback, I'd like to remove or hide it.

I'll try and add a flag for toggling this information on and make it off by default.

That would be nice.

[wjwwood]

I upgraded this to a pull request. Now you can set the /capability_server/debug ROS parameter to true in order to get the tracebacks as debug messages. The demo.launch file also takes a debug launch file argument. Now it looks like this:

% roslaunch capabilities demo.launch debug:=true
... logging to /Users/william/.ros/log/5b41e9e1-1a9e-11e3-8047-542696cef915/roslaunch-dosa-92419.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt

started roslaunch server http://dosa:58326/

SUMMARY
========

PARAMETERS
 * /capability_server/debug
 * /rosdistro
 * /rosversion

NODES
  /
    capability_server (capabilities/capability_server)

auto-starting new master
process[master]: started with pid [92426]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 5b41e9e1-1a9e-11e3-8047-542696cef915
process[rosout-1]: started with pid [92429]
started core service [/rosout]
process[capability_server-2]: started with pid [92430]
[DEBUG] [WallTime: 1378875320.669286] Debug messages enabled.
[INFO] [WallTime: 1378875320.669736] Capability Server Ready
[DEBUG] [WallTime: 1378875320.670099] node[/capability_server, http://dosa:58372/] entering spin(), pid[92430]
[INFO] [WallTime: 1378875327.950469] Request to stop capability 'minimal_pkg/Minimal'
[DEBUG] [WallTime: 1378875327.951270] Traceback (most recent call last):
  File "/Users/william/devel/capabilities/src/capabilities/server.py", line 284, in __catch_and_log
    return func(*args, **kwargs)
  File "/Users/william/devel/capabilities/src/capabilities/server.py", line 498, in _handle_stop_capability
    raise RuntimeError("No Capability '{0}' running".format(capability))
RuntimeError: No Capability 'minimal_pkg/Minimal' running

[ERROR] [WallTime: 1378875327.951606] RuntimeError: No Capability 'minimal_pkg/Minimal' running
^C[capability_server-2] killing on exit
[DEBUG] [WallTime: 1378875331.558635] connecting to dosa 58379
[DEBUG] [WallTime: 1378875331.559658] TCPServer[58379] shutting down
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

---

% roslaunch capabilities demo.launch
... logging to /Users/william/.ros/log/6d9d93ee-1a9e-11e3-a176-542696cef915/roslaunch-dosa-92505.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt

started roslaunch server http://dosa:58467/

SUMMARY
========

PARAMETERS
 * /rosdistro
 * /rosversion

NODES
  /
    capability_server (capabilities/capability_server)

auto-starting new master
process[master]: started with pid [92512]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 6d9d93ee-1a9e-11e3-a176-542696cef915
process[rosout-1]: started with pid [92515]
started core service [/rosout]
process[capability_server-2]: started with pid [92516]
[INFO] [WallTime: 1378875351.449865] Capability Server Ready
[INFO] [WallTime: 1378875354.804300] Request to stop capability 'minimal_pkg/Minimal'
[ERROR] [WallTime: 1378875354.805116] RuntimeError: No Capability 'minimal_pkg/Minimal' running
^C[capability_server-2] killing on exit
[rosout-1] killing on exit
[master] killing on exit
gishutting down processing monitor...
... shutting down processing monitor complete
done

[wjwwood]

I still need to look for any other places tracebacks might bubble up.

[wjwwood]

I will open new issues if I find more exceptions that need catching and logging. Merging this for now.

[bit-pirate]

Nice! Just tested it. I'll report any unmanaged tracebacks I find.