From 0db95259db5b310c8c4ac9b97ca2b6ae075c06e5 Mon Sep 17 00:00:00 2001 From: David Lord Date: Tue, 28 Jul 2020 07:57:24 -0700 Subject: [PATCH] normalize sentence spacing --- docs/errorhandling.rst | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/errorhandling.rst b/docs/errorhandling.rst index 37f02bd6..bb907533 100644 --- a/docs/errorhandling.rst +++ b/docs/errorhandling.rst @@ -3,10 +3,10 @@ Handling Application Errors .. versionadded:: 0.3 -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 -exceptions from time to time. Why? Because everything else involved will -fail. Here are some situations where perfectly fine code can lead to server +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 +exceptions from time to time. Why? Because everything else involved will +fail. Here are some situations where perfectly fine code can lead to server errors: - the client terminated the request early and the application was still @@ -18,8 +18,8 @@ errors: - a programming error in a library you are using - network connection of the server to another system failed -And that's just a small sample of issues you could be facing. So how do we -deal with that sort of problem? By default if your application runs in +And that's just a small sample of issues you could be facing. So how do we +deal with that sort of problem? By default if your application runs in production mode, and an exception is raised Flask will display a very simple page for you and log the exception to the :attr:`~flask.Flask.logger`. @@ -39,21 +39,21 @@ even if the application behaves correctly: *403 Forbidden* If you have some kind of access control on your website, you will have - to send a 403 code for disallowed resources. So make sure the user + to send a 403 code for disallowed resources. So make sure the user is not lost when they try to access a forbidden resource. *404 Not Found* - The good old "chap, you made a mistake typing that URL" message. So + The good old "chap, you made a mistake typing that URL" message. So common that even novices to the internet know that 404 means: damn, - the thing I was looking for is not there. It's a very good idea to + the thing I was looking for is not there. It's a very good idea to make sure there is actually something useful on a 404 page, at least a link back to the index. *410 Gone* Did you know that there the "404 Not Found" has a brother named "410 - Gone"? Few people actually implement that, but the idea is that + Gone"? Few people actually implement that, but the idea is that resources that previously existed and got deleted answer with 410 - instead of 404. If you are not deleting documents permanently from + instead of 404. If you are not deleting documents permanently from the database but just mark them as deleted, do the user a favour and use the 410 code instead and display a message that what they were looking for was deleted for all eternity. @@ -69,7 +69,7 @@ Error Logging Tools Sending error mails, even if just for critical ones, can become overwhelming if enough users are hitting the error and log files are typically never looked at. This is why we recommend using `Sentry -`_ for dealing with application errors. It's +`_ for dealing with application errors. It's available as an Open Source project `on GitHub `_ and is also available as a `hosted version `_ which you can try for free. Sentry @@ -98,7 +98,7 @@ receive error notifications. Follow-up reads: * Sentry also supports catching errors from your worker queue (RQ, Celery) in a - similar fashion. See the `Python SDK docs + similar fashion. See the `Python SDK docs `_ for more information. * `Getting started with Sentry `_ * `Flask-specific documentation `_. @@ -422,7 +422,7 @@ Blueprint Error Handling ```````````````````````` In blueprints, error handlers will work as expected. However, there is a caveat -concerning handlers for 404 and 405 exceptions. These error handlers are only +concerning handlers for 404 and 405 exceptions. These error handlers are only invoked from an appropriate ``raise`` statement or a call to ``abort`` in another of the blueprint's view functions; they are not invoked by, e.g., an invalid URL access. @@ -559,11 +559,11 @@ full-featured Python debugger. When in Doubt, Run Manually --------------------------- -Having problems getting your application configured for production? If you +Having problems getting your application configured for production? If you have shell access to your host, verify that you can run your application -manually from the shell in the deployment environment. Be sure to run under +manually from the shell in the deployment environment. Be sure to run under the same user account as the configured deployment to troubleshoot permission -issues. You can use Flask's builtin development server with `debug=True` on +issues. You can use Flask's builtin development server with `debug=True` on your production host, which is helpful in catching configuration issues, but **be sure to do this temporarily in a controlled environment.** Do not run in production with `debug=True`. @@ -575,8 +575,8 @@ Working with Debuggers ---------------------- To dig deeper, possibly to trace code execution, Flask provides a debugger out -of the box (see :ref:`debug-mode`). If you would like to use another Python -debugger, note that debuggers interfere with each other. You have to set some +of the box (see :ref:`debug-mode`). If you would like to use another Python +debugger, note that debuggers interfere with each other. You have to set some options in order to use your favorite debugger: * ``debug`` - whether to enable debug mode and catch exceptions