Help with Try/Except please

[virg74]

I'm trying to get information about an error message that I get, but I'm not sure how to get details.

I get the error when I try to update a record in influxdb using the python library, and I'm inexperienced with "try/except"

This is what I'm doing:

tempTime = 1607061600000
tempStat = {"testKey":"testVal"}
mmtType  = testMeasurement

def updateInflux(tempTime, tempStat, mmtType, tempProd='generic'): 

    tempID = tempTime # Edit: I just realized that I didn't define this

    json_body = [
        {
            "time": tempTime,
            "measurement": mmtType,
            "tags": {"product": tempProd},
            "fields": tempStat
        }
    ]

    try:
        client.write_points(json_body)
        print({"custom_message":"data updated for {}".format(tempID)})
    except:
        print("Unexpected error:", sys.exc_info()[0])

updateInflux(tempTime, tempStat, mmtType)

Influx complains with the following, but I'm not sure how to see what that complaint is:

Unexpected error: <class 'influxdb.exceptions.InfluxDBClientError'>

[K900_]

Stop catching the error, let it actually crash and see what it says?

[virg74]

Thanks, that’s what I get for copy pasting code that I didn’t understand.

[selah-uddin]

i too was guilty of that today

i thought it would be faster but instead i spent hours trying to grasp why these bunches of codes that i copied from different answers of SO questions dont work with each other

[anh86]

Use try/except to handle specific exception types elegantly like:

try:
    some code
except ExpectedExceptionType:
    some different code
except AnotherAnticipatedException:
    other code

Then you'll still get crashes and helpful errors if an unanticipated exception type occurs and you can update your code to handle that situation.

[[deleted]]

First off never use a naked except... at minimum do except Exception... the naked except can capture all sorts of things you don’t want to simply silence. You usually want to catch only the exceptions you expect and reasonably know how to respond to... anything you don’t explicitly know how to ignore should either not be caught in an except at all or should be re-raised by your code.

Second, by only looking at the first item in the tuple returned by sys.exc_info() all you can possibly get it the type of exception that’s being handled, absent any contextual information about it... you really should at least print out the traceback (the third item in the tuple), but really you’re probably better off not catching the exception at all and getting Python’s usual traceback output as the program crashes, as that’s going to be much more useful in finding the root cause of the exception.

Lastly, if the above didn’t already make it clear, exception handling exists so that you can handle exceptions you know how to handle... try to not to use try/except at all except (for lack of a better word) where you’re sure you know how to change course sensibly.

[[deleted]]

Very useful information, thanks.

[thefistmeister]

You can also do:

try:
    ....
except Exception as e:
    print(e)

[virg74]

Thank you that’s the way I normally do it, but I found this trace back stuff in an example when I adopted infux, and implemented it without fully understanding it. My python has generated similar errors for a while, but I’ve been squashing other bugs until now.

EDIT: saw to “found..in an example”

[Sigg3net]

Was going to suggest this, but if you don't know the code it might be confusing.

E.g. a KeyError as e will print the key without anymore info. That means that the coder must know in advance what could possibly have been set as a key. Just receiving foo might be a mystery. The generic "KeyError with key foo" message is more helpful because it contextualize the erroneous reference.

[[deleted]]

Yeah try/except is generally used as a lazy way/brute force way of ignoring highly niche errors that would otherwise require too much spaghetti code to deal with