errors from background tasks are not printed

[bartlomieju]

Given:

import responder
# import time <- notice missing import

api = responder.API()

@api.route("/")
def hello(req, resp):

    @api.background.task
    def sleep(s=1):
        time.sleep(s)
        print("slept!")

    sleep()
    resp.content = "processing"

if __name__ == '__main__':
    api.run()

When running sleep NameError is thrown but no output is shown in console.

[kennethreitz]

we need to add logging.

[condemil]

The exception is happening in separate thread that is the reason it is not printed.

@kennethreitz What do you think will be the best approach to handle exception in futures? It is possible to have a custom ThreadPoolExecutor as it is proposed here.

[vuonghv]

@kennethreitz What about passing callback functions to @api.background.task to handle success and error case. I'm implementing this feature, and the following is demo api:

def on_success(result):
     print(result)

def on_error(error):
    print(error)

@api.background.task(on_success, on_error)
def sleep(s=10):
     # Do background tasks here

[pbsds]

@kennethreitz What about passing callback functions to @api.background.task to handle success and error case. I'm implementing this feature, and the following is demo api:

def on_success(result):
     print(result)

def on_error(error):
    print(error)

@api.background.task(on_success, on_error)
def sleep(s=10):
     # Do background tasks here

Although neat, this is dangerously close the Deferred structures used in Twisted. We use async and await to avoid that callback mess. I say ensuring exception are printed should be enough. Leaving the error handling up to the user is a lot more readable. Creating a separate decorator for this kind of error handling should be trivial should the user want it.

[kennethreitz]

I feel if you want something more sussinct, you should just use async/await