calpoly-csai / api

Official API for the NIMBUS Voice Assistant accessible via HTTP REST protocol.
https://nimbus.api.calpolycsai.com/
GNU General Public License v3.0
9 stars 4 forks source link

Generic Error handling #182

Closed snekiam closed 4 years ago

snekiam commented 4 years ago

Objective

Similar to the way we handle OperationalError in the flask_api, we should have a catchall to log what happens for uncaught exeptions

Key Result

Details

(as of now) Flask_api has the following:

@app.errorhandler(OperationalError)
def handle_database_error(error):
    global db
    if db is None:
        # reinit the database
        init_nimbus_db()
    else:
        # we *probably* have a bad session - try and roll it back,
        # then create a new database connection.
        db.session.rollback()
        db.session.close()
        db = None
        init_nimbus_db()

to catch OperationalErrors. We should modify this/change this to handle more than just OperationalErrors (like IndexErrors, etc) and log them.

Additional context Python errors all follow object oriented design (I think), so I think we can catch a generic Exception and check what type it is to handle different ones differently.

ethanahlquist commented 4 years ago

@snekiam Howdy, I have been looking into making the catchall handler, and have come up with some ideas in the iss182_catchall_logger branch.

One issue I was having was using the Flask-based Exception handling. It was not able to handle the exceptions we have been discussing. I think this is because they are Errors in the database query, not a Flask one.

Also, the database needs to be updated to allow storage of the new data. Which I think I could do, but I don't want to mess up the data.

I'm guessing this can be figured out on Sunday, but for the future I can also work on most days.

snekiam commented 4 years ago

@ethanahlquist Hmm, I thought you could catch any exception through the flask error handler - I think OperationalError is from sqlalchemy. Lets talk about it today.