Beautify error output

[goldhoorn]

"Normal" errors should be only display the relevant information:

orocos.rb[FATAL]: killing running task contexts and deployments because of unhandled exception
orocos.rb[FATAL]:   /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:139:in `rescue in block in setup_task': no transformation from 'body' to 'odometry' available, required by /slam for body => odometry

Current output:

orocos.rb[WARN]: killing running task contexts and deployments because of unhandled exception
orocos.rb[WARN]:   /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:139:in `rescue in block in setup_task': no transformation from 'body' to 'odometry' available, required by /slam for body => odometry
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:137:in `block in setup_task'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/share/orogen/plugins/transformer_plugin.rb:486:in `each'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/share/orogen/plugins/transformer_plugin.rb:486:in `each_needed_transformation'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:120:in `setup_task'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:61:in `block in setup'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:60:in `each'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/install/lib/ruby/2.1.0/transformer/runtime.rb:60:in `setup'
orocos.rb[WARN]:     start_sim.rb:62:in `block in <main>'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/tools/orocos.rb/lib/orocos/process.rb:830:in `block in run'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/tools/orocos.rb/lib/orocos/process.rb:1241:in `guard'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/tools/orocos.rb/lib/orocos/process.rb:829:in `run'
orocos.rb[WARN]:     /home/goldhoorn/bootstraps/tools/orocos.rb/lib/orocos/process.rb:136:in `run'
orocos.rb[WARN]:     start_sim.rb:19:in `<main>'

[goldhoorn]

Furthermore the output is displayed twice (once in colors, once regular)

[doudou]

Avoid backtrace filtering at all bloody cost unless you are in an extremely controlled environment. Errors are usually not due to the last line in the backtrace.

I however agree with the problem of having a backtrace twice. The reason is that sometimes killing the processes takes long, and it annoys people to not know why their script fail (they usually don't care about killing not working properly)

[goldhoorn]

But in this case (we raising a specific error) it makes not sense to pass the complete back trace to the customer (from my point of view). Specially new-customers often don't read back traces.

[doudou]

Please stop talking about customers. Please. That really only makes me want to simply ignore this thread. The day I get a contract and a check, they become my customers.

First of all, "we" are raising no specific anything. The transformer extension does. So, unless you want your low-level API to know about every single extension possible, "it" dos not kow anything about anything.

I've been doing heavy backtrace filtering for a long while, and I tell you from experience that filtering backtraces heavily annoys more people than telling them how to read a backtrace would. How annoyed have you ever been with the dreaded

terminate because of unhandled exception: std::bad_alloc

Telling where the bad_alloc has been thrown does not help, because it does not say "why". The "why" is between the last line and the first, and if we were able to know "where* we would have automated debugging tools.

The only two things you could kind-of safely filter here is:

• the part between the two start_sim lines (because you might be able to assume that this part of the
  non-user code is "fine" since it actually passed to the user code. Of course, this asks for the next
  question: what is framework code ? And who should do that filtering ?
• the transformer stuff you could maybe, but that should be the job of the transformer, not of orocos.rb

In other words: it has to be done on a case-by-case basis.

A possibility to help libraries would be to have rock-run wrap the require'd script and pretty-print exceptions, and then let the rest of the libraries choose which exceptions to filter and which to not. Maybe. Not even sure about that.

[goldhoorn]

Ok let me rephrase it: s/customers/users/g (users != rock-developers)

However, what i wanted to point out is the following:

• The problem that a task cannot be found
• The transformer fails
• A config file has no correct section
• A member in a config-file is wrong

Should not produce THAT much output, backtrace information are (from my point of view) in this use-cases (user writes a script) are unneeded. This backtrace information ARE useful if they are called from a higher-level like syskit, but under scripting Operations they are simply too much. Even i get annoyed if i have to scroll and search in the back trace for the error.

However i have no real solution for this I just wanted to point out with this issue that i believe rock is on this layer where each rock-users starts (scripting layer) too much speaky....

P.S. please don't feel attacked, i only know that apple and other software engineers CAN provide short error messages.
P.P.S.: https://en.wiktionary.org/wiki/customer customers can receive products, i see the rock-core toolchain in this case as something we (the rock-core-dev's) provide to other people.

[doudou]

please don't feel attacked, i only know that apple and other software engineers CAN provide short

I don't, these backtraces annoy me as well.

What I tried to tell you previously is that it is something one CAN do, but on a per-exception basis. Which is exactly what you are saying yourself: "a task cannot be found", "a config file does not have a correct section", ... These are specific exceptions where the source of the error is exactly known (the section name is wrong). For those, it is possible to provide a per-exception "beautified" output to your user which is (1) formatted properly and (2) shows only the relevant bits of the backtrace.

On an implementation side, this is not a orocos.rb bug, but something that has to be done by everyone:

• define #pretty_print on these errors, which would do backtrace filtering (and display the non-filtered backtrace on e.g. a debug logger)
• wrap the scripts in an executor which can handle these (e.g. rock-run)

(For what it's worth, it's the strategy for model loading errors in roby, and it works decently well).

i only know that apple and other software engineers CAN provide short error messages

I laughed so much reading this. My experience of spending countless hours spent trying to find out why big name application "does not just work" tells me otherwise.