# Troubleshooting Client Event Scripts **URL:** \ **Category:** General Discussion\ **Created:** [March 9, 2022, 4:45pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020 "2022-03-09T16:45:26Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![William\_R](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/william_r/32/32710_2.png) [@William\_R](https://forum.inductiveautomation.com/u/William_R)\ **Post date:** [March 9, 2022, 4:45pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/1 "2022-03-09T16:45:26Z")
Hi Everyone, I have a question on best practices and most efficient ways to trouble shoot gateway tag change event scripts? I can’t use the script console because my scripts always have event tag paths, parent paths, etc. and errors always pop up for the variables not being defined. Is there a way around this? If not, what is the best way to troubleshoot the gateway scripts? I have realized that my gateway script stops executing on an error, which I must currently have in my script. Though, its not a compile error. On top of not being a compile error, my java exception doesn’t catch the error either. Thanks for the help. -William ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 9, 2022, 6:29pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/2 "2022-03-09T18:29:39Z")
Use loggers liberally at debug level throughout the script. > [@What is your preferred way of logging debugging info?](https://forum.inductiveautomation.com/t/what-is-your-preferred-way-of-logging-debugging-info/56404/2): > > I create and use loggers named by the project and script they are in, created as top-level objects. Sometimes multiple loggers in a script module if necessary. Then I log profusely at debug level. When debugging, it offers many options to selectively enable DEBUG level to narrow down the problem. When first writing a script, I do so for 1 tag, I hard code the tagPath and/or parent paths, and other things and insure that the script works as expected. Then I move on to a list of hardcoded paths if needed, before I ever actually implement it in the gateway. Even then I still insure that I use a logger, sometimes even multiple loggers in the same script, so I can look back and get an idea of what went wrong. > [@William\_R](#): > > my java exception doesn’t catch the error either. Use multiple except blocks to ensure you catch jython exceptions as well as java exceptions. > [@Catch IOException?](https://forum.inductiveautomation.com/t/catch-ioexception/18612/3): > > Consider using two except blocks, as jython’s standard Exception won’t catch pure java exceptions. Like so: import java.lang.Exception try: # something something something except Exception, e: # jython exception except java.lang.Exception, e: # java exception ---
**Author:** ![William\_R](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/william_r/32/32710_2.png) [@William\_R](https://forum.inductiveautomation.com/u/William_R)\ **Post date:** [March 9, 2022, 6:43pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/3 "2022-03-09T18:43:54Z")
Wow! Tons of great content there. Thank you. -William ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 9, 2022, 7:04pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/4 "2022-03-09T19:04:34Z")
Nowadays I usually use `from java.lang import Throwable` and catch `Throwable` instead of `java.lang.Exception`. Better coverage. ---
**Author:** ![William\_R](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/william_r/32/32710_2.png) [@William\_R](https://forum.inductiveautomation.com/u/William_R)\ **Post date:** [March 9, 2022, 9:16pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/5 "2022-03-09T21:16:59Z")
> [@pturmel](#): > > Nowadays I usually use `from java.lang import Throwable` and catch `Throwable` instead of `java.lang.Exception` . Better coverage. Thanks for the tip. Do you by chance have a link that explains throwables and how to use them? I have never used them before and I didn't find anything about them in a search for Ignition 8.1 manual. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 9, 2022, 9:46pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/6 "2022-03-09T21:46:08Z")
[Throwable](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html) is the ultimate parent of all java exceptions and errors. It is the container for anything that has the structure `message`, `traceback`, and `cause`. Ignition’s loggers have method signatures that include `Throwable` for when you wish your log entry to have a stack trace attached. That’s particularly valuable when you are suppressing an error but want the source reported. My `later.py` script includes a class that can wrap a jython exception in java format so you can log it with the jython traceback (mostly) intact. ---
**Author:** ![William\_R](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/william_r/32/32710_2.png) [@William\_R](https://forum.inductiveautomation.com/u/William_R)\ **Post date:** [March 9, 2022, 10:00pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/7 "2022-03-09T22:00:15Z")
> [@pturmel](#): > > My `later.py` script includes a class that can wrap a jython exception in java format so you can log it with the jython traceback (mostly) intact. Where can I access this script? Thanks for your response, though unfortunately it unravels more questions for me. I need to learn what loggers and stack traces are. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 9, 2022, 10:30pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/8 "2022-03-09T22:30:29Z")
Its permanent home is here: [later.py](https://www.automation-pros.com/ignition/later.py). Search this forum for it for many usage discussions. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 9, 2022, 11:30pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/9 "2022-03-09T23:30:55Z")
> [@William\_R](#): > > I need to learn what loggers and stack traces are. Loggers are objects that, well, log. Specifically they are wrappers that write messages to the console log at specific levels. Where exactly you go to see that message depends on the scope in which it is called. You use `system.util.getLogger()` to get a reference to a LoggerEx object which has specific functions which log the messages at different levels. [https://docs.inductiveautomation.com/display/DOC81/system.util.getLogger](https://docs.inductiveautomation.com/display/DOC81/system.util.getLogger) Stack traces, basically, are a list of function calls leading from the function in which code is currently being executed back to the top. Think of it like this, each time a function is called, it is placed on a pile, subsequent function calls are placed on top, before you can remove one from the pile it must complete its execution and complete. You can only remove things from the top of the pile, and thus it’s called a stack. Another name you might see for this type of structure is LIFO (last in first out). It is often included in debug messages to help indicate the path the program took to generate the error. This is useful when a function can be called from many places. You’ve undoubtedly seen a stack trace, probably even used it to debug, and just didn’t know that it was called a stack trace. Of course there is a more technical definition for why it’s called a stack trace but that’s not entirely relevant here. ---
**Author:** ![William\_R](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/william_r/32/32710_2.png) [@William\_R](https://forum.inductiveautomation.com/u/William_R)\ **Post date:** [March 10, 2022, 2:38pm UTC](https://forum.inductiveautomation.com/t/troubleshooting-client-event-scripts/57020/10 "2022-03-10T14:38:14Z")
Thank you @lrose and @pturmel for your help on this.