Closed haider8645 closed 1 year ago
I would be much cleaner to catch the exception and print the error there, but as the transformer task does not actually calling these functions, and other rock users might forget to catch the exceptions in their code, printing the error here does actually improve their search for the error. I'll merge it.
I would be much cleaner to catch the exception and print the error there,
The components should already be doing that on exception (they show the what() of an exception when catching it). Maybe what @haider8645 was missing is the offending method ?
Could be that they don't show/aren't catched, becauce e.g. registerTransformation() is called in the task constructor and not in a hook.
For me the trajectory_follower was going in Exception state on startup. The reason for it was the transformation robot2map did not have a time stamp. This transformation is provided by the slam task. I had to put the trajectory follower update hook into a try catch to catch this exception but this would mean that I would need to do this for every task which uses the transformer to see the exception message. So, the added logs although not clean, atleast will make the error appear in the log directly. I do not know what you mean by the offending method?
I had to put the trajectory follower update hook into a try catch to catch this exception
Thanks for the details @haider8645. You should not have to catch it, because the rock components should catch exceptions that leak out of updateHook and display the what()
It was a tedious task to find out why a task which uses the transformer was going in exception. Since the task already uses base-logging, these additional logs will reduce the debugging time.