maya-chen/flask
1
0
Fork 0
forked from orbit-oss/flask
Code Pull requests Activity

rewrite external debuggers section

Browse source
This commit is contained in:
David Lord 2020-07-28 07:59:19 -07:00
parent 0db95259db
commit 2db3c9a72e
No known key found for this signature in database
GPG key ID: 7A1C87E3F5BC42A8
1 changed files with 23 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

50
docs/errorhandling.rst
View file

@ -1,8 +1,6 @@
Handling Application Errors Handling Application Errors
=========================== ===========================
.. versionadded:: 0.3
Applications fail, servers fail. Sooner or later you will see an exception Applications fail, servers fail. Sooner or later you will see an exception
in production. Even if your code is 100% correct, you will still see in production. Even if your code is 100% correct, you will still see
exceptions from time to time. Why? Because everything else involved will exceptions from time to time. Why? Because everything else involved will
@ -574,36 +572,34 @@ production with `debug=True`.
Working with Debuggers Working with Debuggers
---------------------- ----------------------
To dig deeper, possibly to trace code execution, Flask provides a debugger out The built-in development server provides a :ref:`debug-mode` that shows
of the box (see :ref:`debug-mode`). If you would like to use another Python an interactive traceback in the browser when an unhandled error occurs
debugger, note that debuggers interfere with each other. You have to set some during a request.
options in order to use your favorite debugger:
* ``debug`` - whether to enable debug mode and catch exceptions External debuggers, such as those provided by IDEs, can offer a much
* ``use_debugger`` - whether to use the internal Flask debugger more powerful and visual debugging experience. They can also be used to
* ``use_reloader`` - whether to reload and fork the process if modules step through code during a request before an error is raised, or if no
were changed error is raised.
``debug`` must be True (i.e., exceptions must be caught) in order for the other When using an external debugger, the app should still be in debug mode,
two options to have any value. but it can be useful to disable the built-in debugger and reloader,
which can interfere.
If you're using Aptana/Eclipse for debugging you'll need to set both When running from the command line:
``use_debugger`` and ``use_reloader`` to False.
A possible useful pattern for configuration is to set the following in your .. code-block:: text
config.yaml (change the block as appropriate for your application, of course)::
FLASK: $ export FLASK_ENV=development
DEBUG: True $ flask run --no-debugger --no-reload
DEBUG_WITH_APTANA: True
Then in your application's entry-point (main.py), When running from Python:
you could have something like::
if __name__ == "__main__": .. code-block:: python
# To allow aptana to receive errors, set use_debugger=False
app = create_app(config="config.yaml")
use_debugger = app.debug and not(app.config.get('DEBUG_WITH_APTANA')) app.run(debug=True, use_debugger=False, use_reloader=False)
app.run(use_debugger=use_debugger, debug=app.debug,
use_reloader=use_debugger, host='0.0.0.0') Disabling these isn't required, an external debugger will continue to
work with the following caveats. If the built-in debugger is not
disabled, it will catch unhandled exceptions before the external
debugger can. If the reloader is not disabled, it could cause an
unexpected reload if code changes during debugging.