Global error capture

[i-terezie]

In the process of integrating Espruino into my project, I tried to solve the problem of integrating error messages from the JS interpreter into the logging system used in my computer project. And I came across the almost unrealizability of this task. I wanted errors that occur during the startup and execution of the script to be redirected as error messages to my logging system in the form of error messages. The main problem is in the non-formalized form of error messages issued by the interpreter. An obvious solution could be to have a method that transmits uncaught errors so that I can then output them in the form that is convenient for me. But I didn't find it, maybe it exists, then please give me a link to it.

In the course of the experiments, I found a strange case where an error should be issued, but it is not issued:

console.log('.bootcde Stateted');

require("Storage").write("answer.js",`
9809---1231
exports.get = function() {
return 42--8;
};
`)

var x=require("answer.js");
console.log("x:",x);

In this case, there is a syntax error in the line "9809---1231 ", but the interpreter does not respond to it, but simply ignores the rest of the answer.js, which is at least not logical. There is an error, but it has not been reported. At the same time, the exact same line in .bootcde throws an error.

[gfwilliams]

Ok, so the actual issue here is that if a library throws an exception when initialising, it's not rethrown?

If you want to handle/report errors when they occur, what about https://www.espruino.com/Reference#l_process_uncaughtException ? that should be called for any errors that would normally be reported on the console

[i-terezie]

Ok, so the actual issue here is that if a library throws an exception when initialising, it's not rethrown?

Maybe. I do not know exactly how this happens inside, but it does not reach the console.

If you want to handle/report errors when they occur, what about https://www.espruino.com/Reference#l_process_uncaughtException ? that should be called for any errors that would normally be reported on the console

Thanks, I'll try it today.

I was dealing with parsing messages in the console yesterday. And I found IMHO a good method of separating messages. I divide them by the ESC codes of the beginning ("\x0d\x1B[J") and the end ("\x0d\x0a>"). And I came up with the idea that can develop this principle and divide the messages into 6 groups by adding ESC color sequences. Plain text - without additional sequences. Add a color coloring for the console: console.debug(text, ...) - white on a gray background; console.error(text, ...) - white on a red background; console.info (text, ...) - black on a gray background; console.log(text, ...) - green on a gray background; console.warn(text, ...) - black on a yellow background; The colors are more for example and they should be chosen more carefully.

In this case, two tasks are solved: The first is to make the console more readable, due to the color separation of message types. The second option is to split messages to transfer them to the structure of the log system

[gfwilliams]

Yes, that was suggested when console.warn/etc were added recently, but other users/apps do already depend on the data coming out of console.log in a certain format, so if we changed it globally they would break.

Nothing stops you from adding the code to overwrite console.warn/etc to your program though (or even to .boot0 to ensure it's always run) so that on your device things are output the correct way.

FYI there are already some docs on how to save messages to memory when you're not connected at https://www.espruino.com/Debugger

[i-terezie]

I tried the debugger. I will use it. But he didn't do anything intelligible with the example I gave in the first message. It just falls off on a line with a syntax error. Error interception doesn't catch it either.

In all other cases, error interception works.

Thanks for the advice, I think that now I can do everything I need to do.

[gfwilliams]

But he didn't do anything intelligible with the example I gave in the first message

It's because you presumably inserted debugger right into the code you uploaded to RAM (which is run as it is uploaded). See https://www.espruino.com/Saving

If the debugger keyword gets called after upload, it'll work more as expected

[i-terezie]

No. I understood that it does not work with the code in memory. In this case, the code was uploaded to Flash. Most likely, as you assumed earlier, an exception occurred, and later it died somewhere in the processing chain.

By the way, regarding the improvements in the console, you can make a call that will specify the version of the console's appearance. In this case, the default will be what it is now, and for the rest of the cases, you can choose a beautiful version of the console. The only thing is to think carefully about the new version, so as not to produce many versions later.