Printing stack trace to gateway logs from a try

Ignition
,
1

Hey folks,

We have a gateway script running stored procedures. If a stored procedure fails, we need to notify the users so they know to halt the process and review the data. However, by implementing a try, we lose out on the stack trace that would ordinarily print to the gateway logs.

Ideally, we allow the error to hit the logs naturally and we take action to alert the users. However it seems like we need to do both in our except in order to make it happen. Is there any way to print a complete stack trace from a try? Ideally, it would mimic the standard stack trace, with the option to expand for details rather than filling the log with a wall of text.

I've been working with support and right now we're at a bit of an impasse with the following.
(This code is incomplete in that it's not in a logger, just showcasing what we have)

import java.lang.Throwable

tag = 123
db = "DB_Doesnt_Exist"

try:
    Custom.Function.Calling.Sproc(tag, db)

except java.lang.Throwable, e:
    #prints full stack trace and back trace to console.
    #This has all the information we want, but cannot seem to redirect to gateway logs
    e.printStackTrace()

    #print the general error mesage
    print e.getMessage()

    #print the stack trace line-by-line
    #does not contain back trace
    stack = e.getStackTrace()
    for trace in stack:
        print trace
2

system.util.getLogger("someLogger").error("some message", someException)

2 Likes
3

Fundamentally, the problem is that print doesn't go to the logging subsystem. It just goes out the JVM's standard output. (Which is connected to the console window in the designer and in Vision clients.)

Always use loggers. Use the logger methods that have a throwable argument to get a throwable's stack trace in to the log. If you need python traces, too, use the PythonAsJavaException wrapper class from later.py to make them acceptable to the logger methods.

1 Like
4

Thank you, both.

I just stumbled upon this solution while I was working through hail-mary options. The face-palm moment was audible in my office.

I think my confusion could have been dissapated much earlier in the process if I'd known that system.util.logger could process throwables. The documentation does not indicate this anywhere, and I (and IA phone support) spent an inordinate amount of time trying to process a throwable into a string that I could pass to the logger.

:man_facepalming:

myLogger = system.util.getLogger("TestLogger")
try:
    Custom.Function.Calling.Sproc(tag, db)
except java.lang.Throwable, e:
    myLogger.error("Error Message", e)
5

The "returns" part of the documentation links to the javadoc for LoggerEx, which shows the rest of the available methods.

The current docs should be pointing to v8.1 javadoc, but whatever.

6

Thanks, Phil.

I hadn't noticed that.

Still, I think it would be a nice example to add to the docs on that page. I worked with 2 IA reps, my client, and office mates today and none of us were aware of this capability. :slight_smile:

1 Like
7

Tangent, but might be good to relax that requirement. I'll put it on the long list of ideas to explore. A "solution" to the split throwable types issue would be nice, though if Jython devs haven't come up with it it's probably not forthcoming.

8

Python and Java traceback information is just different enough that it is ugly to convert. As my implementation shows. The core of the issue is that PyException must be a subclass of PyObject, and other PyObjects cannot be subclasses of Throwable. Noodle on that. (Multiple inheritance for the win!)

9

I think you can just re-raise caught exceptions after doing whatever you need to do with them.

I use something like this:

try:
	0/0
except ZeroDivisionError:
	message = "You divided by zero"
	raise
finally:
	print(message)

And I believe I get the full stacktrace in the logs.
I'll have to check, it's been a while since I wrote the wrappers I use to handle it.
I re-raise errors in case I need to handle them in some higher layer, instead of just logging them.
And if you don't catch them, they'll be logged naturally.

10

Neat - I'd have not thought to try it that way. I'll have to test it and see what I get!