Proposal for user friendly error reporting in iotjs

[Zoltan Herczeg]

Currently IoT.js reports simple error strings if an error occurs. It does not show source text and backtrace like nodejs. The primary reason is memory saving, iotjs is designed for low memory environments.

However, users prefer to see a detailed error log, at least in debug mode. Normally the jerryscript debugger provides a great tool for that, but some people does not like using two terminals, and want to see only the last (uncaught) error.

My proposal is creating a script such as iotjs_debug. The name can be changed of course. This script is both an iotjs runner and a simple debugger client. When iotjs_debug arg1, arg2, ... is executed, the following steps are taken:

1. Runs iotjs with the arguments + starts a debug server:
   iotjs --start-debug-server arg1, arg2, ...
2. Creates a debugger client which does not have a console. The client collects the source code info, and other debugging data.
3. If iotjs stops with an error, it displays the source text and backtrace for the error.

Would this be a good solution to provide user friendly errors?

Could fix #846

[Daeyeon Jeong]

Thank you for sharing your thought. We have some following queries.

a) In our understanding, the python script runs iotjs --start-debug-server {FILE} and creates a subprocess to run a debugger client, which connects localhost:5001. The iotjs executable should be built with --jerry-debugger, and optionally along with --no-snapshot. Is this interpretation right?

b) It's hard to assume the python dependency on Nuttx and TizenRT.

c) If a) is right, can we embed creating a debugger client on a forked process inside the iotjs executable?

d) We can consider giving such an error log only for user codes. That means that the error from them snapshot can be ignored. Can this option reduce the consideration to implement?

[Zoltan Herczeg]

a) yes, debugger support is needed (if we would have a separate implementation, then we would need to prepare for both the debugger and the other implementation coexist, which would complicate things)
b) you can run this basic debugger client on the desktop (or the full debugger). Usually tools on an RT system are very limited so people need many terminals. It is a problem if the device has no network connection, but this is rare even on low-end. Smart things without some kind of network are not really smart... Currently there is an ongoing work in jerry to support more transportation systems, so usb, bluetooth could be used later.
c) yes, iotjs itself could create the other process
d) yes. snapshots currently are ignored by the debugger. Similar to C callback functions, the user will see the error when it appears in a code "seen" by the debugger.

I am also worry about the memory consumption. Currently we have line information. However, if we want to provide more detailed error position info, we need column info as well, and we need line/col pairs for far more subexpressions than we currently have. This isn't a problem if we use a debugger on a desktop side, but on a device it can consume a lot of space.

[Daeyeon Jeong]

I think the requirement can be summarized as follows.

• No python dependency because of TizenRT and nuttx.
• The way to run user's js must be operated in a single CLI.
• Filename and Line information are mandatory. column is optional.
• backtrace is also required for event listeners or exception handler.

Question: I can see the follwing line/col pair when running a code like const aaa = 0. I'm curious on when jerry can print the log. Is that available especially for Primary expression error?

uncaughtException: SyntaxError: Primary expression expected. [line: 2, column: 10]

[Zoltan Herczeg]

Syntax error is precise, since the parser knows the line info when the error occurs. But this info is thrown away later.

Ok, this feature needs to be separated from the debugger. It will not be used by snapshots.

I don't understand the event listener part. Could you give an example?

[Saif]

Yes. Same here i didn't understand the event listener part it will be better to provide example.

 

[Daeyeon Jeong]

...

var ee = new EventEmitter();

ee.on('event-can-be-sent-from-multiple-places', function() {
  var test; unknown;
})

ee.emit('event-can-be-sent-from-multiple-places');

I mentioned it as a case where the backtrace is helpful.

BTW, just in case, can we turn on this user-friendly reporting in release along with backtrace?

[László Langó]

Yes, backtrace can turn on in release too if you need to.

[Daeyeon Jeong]

# built in debug
TypeError: Expected a function.
    at /home/daeyeon/Code/daeyeon.iotjs/test.js:2

# built in release with js-backtrace option
TypeError
    at /home/daeyeon/Code/daeyeon.iotjs/test.js:2

In release build, the message, Expected a function, isn't printed even with js-backtrace option.
Is it intended? If so, can we optionally enable such a message also just in case?

[Zoltan Herczeg]

Looks like error messages are hard coded for debug at the moment:
https://github.com/Samsung/iotjs/blob/master/cmake/jerry.cmake#L87

Fast workaround:
--jerry-cmake-param "-DFEATURE_ERROR_MESSAGES=ON"

On the long term a build.py option would be the best.

[Daeyeon Jeong]

Thanks for the clarification. I think that we can close this issue.