openhab / openhab-core

Core framework of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
912 stars 420 forks source link

[automation] Allow logging of full stacktrace for automation scripts #1225

Open jpg0 opened 4 years ago

jpg0 commented 4 years ago

Currently any exceptions/errors/whatever throw from automation scripts bubble out of the scripting engine and are caught and the message is logged. The full stack is not logged. Currently to get a full stack trace script writers must wrap their own scripts in logic to catch any exceptions/errors and dump the stack themselves.

I have found that having the full stack can be invaluable when writing scripts. During building ES6 support for automation, I added my own logic in the addon to allow full stacks to be dumped. I believe that the better solution would be to allow users to configure that they want a full stack, and to respect this in the script automation engine. I suspect that the simplest solution would be to define a specific log namespace that these traces go to, and then users can toggle the messages on that namespace to determine whether they get full stacks or not.

I'm happy to submit a PR if there is reasonable agreement here.

5iver commented 4 years ago

Take a look at PR #715 and the reasoning why it was not approved. There is still some cleanup I plan to do for the logging in automation, but it does not look like we will get full stack traces. I implemented a traceback for exceptions in the Jython helper libraries.

jpg0 commented 4 years ago

If so, that's a great shame. It just means that every script that I (and probably everyone) write will need to catch and dump it's own exceptions. I've commented on that PR with my view and I'll keep my fingers crossed, but I can see that it looks pretty decided...

jpg0 commented 4 years ago

FYI I just did a load of refactoring work on my JS libs and it was oh-so-painful without stack traces. I just couldn't do it. So I did these before completing the work:

If OH really won't accept any stack traces (even off-by-default), then I was thinking that another option would be to provide an extension point within the scripting code so that installation of an add-on could enable it by wrapping, logging, rethrowing. I can't see how it can be reasonable at all to provide a dev platform for scripts, but deny any data when scripts fail.