Application Startup and Exception Handling

Contains the application framework, utility functions, exception handler helper functions, and the app’s main() entry point.

class app.LoggingWSGIRequestHandler(request, client_address, server)

Subclass of WSGIRequestHandler allowing us to control WSGI server’s logging

log_message(format: str, *args)

Log a message from within the Python wsgiref simple server

Logging elsewhere logs the incoming request before processing in the responder, making it easier to read the overall log. The wsgi server calls this function at the end of processing. Normally the request would not need to be logged again. However, in order to assure logging of responses with HTTP status other than 200 OK, we log the request again here.

For more info see this article

Parameters:

  • format (str) – Unused, old-style format (see notes)

  • args[0] (str) – HTTP Method and URI (“request”)

  • args[1] (str) – HTTP response status code

  • args[2] (str) – HTTP response content-length

Notes

  • Logs using log, our rotating file logger , rather than using stdout.

  • The format argument is an old C-style format for for producing NCSA Commmon Log Format web server logging.

app.custom_excepthook(exc_type, exc_value, exc_traceback)

Last-chance exception handler

Caution

Hook this as last-chance only after the config info has been initiized and the logger is set up!

Assures that any unhandled exceptions are logged to our logfile. Should “never” be called since unhandled exceptions are theoretically caught in falcon. Well it’s here so the exception has a chance of being logged to our file. It’s used by falcon_uncaught_exception_handler() to make sure exception info is logged instead of going to stdout.

Parameters:

  • exc_type (_type_) – _description_

  • exc_value (_type_) – _description_

  • exc_traceback (_type_) – _description_

Notes

app.falcon_uncaught_exception_handler(req: Request, resp: Response, ex: BaseException, params)

Handle Uncaught Exceptions while in a Falcon Responder

This catches unhandled exceptions within the Falcon responder, logging the info to our log file instead of it being lost to stdout. Then it logs and responds with a 500 Internal Server Error.

app.init_routes(app: App, devname: str, module)

Initialize Falcon routing from URI to responser classses

Inspects a module and finds all classes, assuming they are Falcon responder classes, and calls Falcon to route the corresponding Alpaca URI to each responder. This is done by creating the URI template from the responder class name.

Note that it is sufficient to create the controller instance directly from the type returned by inspect.getmembers() since the instance is saved within Falcon as its resource controller. The responder methods are called with an additional ‘devno’ parameter, containing the device number from the URI. Reject negative device numbers.

Parameters:

  • app (App) – The instance of the Falcon processor app

  • devname (str) – The name of the device (e.g. ‘rotator”)

  • module (module) – Module object containing responder classes

Notes

  • The call to app.add_route() creates the single instance of the router class right in the call, as the second parameter.

  • The device number is extracted from the URI by using an int placeholder in the URI template, and also using a format converter to assure that the number is not negative. If it is, Falcon will send back an HTTP 400 Bad Request.

app.main()

Application startup