CINXE.COM

<!DOCTYPE html> <html lang="en" data-content_root="../"> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Handling Application Errors — Flask Documentation (3.1.x)</title> <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=4f649999" /> <link rel="stylesheet" type="text/css" href="../_static/flask.css?v=b87c8d14" /> <script src="../_static/documentation_options.js?v=d71c4578"></script> <script src="../_static/doctools.js?v=9bcbadda"></script> <script src="../_static/sphinx_highlight.js?v=dc90522c"></script> <link rel="canonical" href="https://flask.palletsprojects.com/en/stable/errorhandling/" /> <link rel="icon" href="../_static/shortcut-icon.png"/> <link rel="index" title="Index" href="../genindex/" /> <link rel="search" title="Search" href="../search/" /> <link rel="next" title="Debugging Application Errors" href="../debugging/" /> <link rel="prev" title="Testing Flask Applications" href="../testing/" /> <script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script><meta name="readthedocs-project-slug" content="flask" /><meta name="readthedocs-version-slug" content="stable" /><meta name="readthedocs-resolver-filename" content="/errorhandling/" /><meta name="readthedocs-http-status" content="200" /></head><body> <div class="related" role="navigation" aria-label="Related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="../genindex/" title="General Index" accesskey="I">index</a></li> <li class="right" > <a href="../py-modindex/" title="Python Module Index" >modules</a> |</li> <li class="right" > <a href="../debugging/" title="Debugging Application Errors" accesskey="N">next</a> |</li> <li class="right" > <a href="../testing/" title="Testing Flask Applications" accesskey="P">previous</a> |</li> <li class="nav-item nav-item-0"><a href="../">Flask Documentation (3.1.x)</a> »</li> <li class="nav-item nav-item-this"><a href="">Handling Application Errors</a></li> </ul> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body" role="main"> <section id="handling-application-errors"> <h1>Handling Application Errors<a class="headerlink" href="#handling-application-errors" title="Link to this heading">¶</a></h1> 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: <ul class="simple"> <li>the client terminated the request early and the application was still reading from the incoming data</li> <li>the database server was overloaded and could not handle the query</li> <li>a filesystem is full</li> <li>a harddrive crashed</li> <li>a backend server overloaded</li> <li>a programming error in a library you are using</li> <li>network connection of the server to another system failed</li> </ul> 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 <a class="reference internal" href="../api/#flask.Flask.logger" title="flask.Flask.logger"><code class="xref py py-attr docutils literal notranslate">logger</code></a>. But there is more you can do, and we will cover some better setups to deal with errors including custom exceptions and 3rd party tools. <section id="error-logging-tools"> <h2>Error Logging Tools<a class="headerlink" href="#error-logging-tools" title="Link to this heading">¶</a></h2> 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 <a class="reference external" href="https://sentry.io/">Sentry</a> for dealing with application errors. It’s available as a source-available project <a class="reference external" href="https://github.com/getsentry/sentry">on GitHub</a> and is also available as a <a class="reference external" href="https://sentry.io/signup/">hosted version</a> which you can try for free. Sentry aggregates duplicate errors, captures the full stack trace and local variables for debugging, and sends you mails based on new errors or frequency thresholds. To use Sentry you need to install the <code class="docutils literal notranslate">sentry-sdk</code> client with extra <code class="docutils literal notranslate">flask</code> dependencies. <div class="highlight-text notranslate"><div class="highlight"><pre>$ pip install sentry-sdk[flask] </pre></div> </div> And then add this to your Flask app: <div class="highlight-python notranslate"><div class="highlight"><pre>import sentry_sdk from sentry_sdk.integrations.flask import FlaskIntegration sentry_sdk.init('YOUR_DSN_HERE', integrations=[FlaskIntegration()]) </pre></div> </div> The <code class="docutils literal notranslate">YOUR_DSN_HERE</code> value needs to be replaced with the DSN value you get from your Sentry installation. After installation, failures leading to an Internal Server Error are automatically reported to Sentry and from there you can receive error notifications. See also: <ul class="simple"> <li>Sentry also supports catching errors from a worker queue (RQ, Celery, etc.) in a similar fashion. See the <a class="reference external" href="https://docs.sentry.io/platforms/python/">Python SDK docs</a> for more information.</li> <li><a class="reference external" href="https://docs.sentry.io/platforms/python/guides/flask/">Flask-specific documentation</a></li> </ul> </section> <section id="error-handlers"> <h2>Error Handlers<a class="headerlink" href="#error-handlers" title="Link to this heading">¶</a></h2> When an error occurs in Flask, an appropriate <a class="reference external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status">HTTP status code</a> will be returned. 400-499 indicate errors with the client’s request data, or about the data requested. 500-599 indicate errors with the server or application itself. You might want to show custom error pages to the user when an error occurs. This can be done by registering error handlers. An error handler is a function that returns a response when a type of error is raised, similar to how a view is a function that returns a response when a request URL is matched. It is passed the instance of the error being handled, which is most likely a <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">HTTPException</code></a>. The status code of the response will not be set to the handler’s code. Make sure to provide the appropriate HTTP status code when returning a response from a handler. <section id="registering"> <h3>Registering<a class="headerlink" href="#registering" title="Link to this heading">¶</a></h3> Register handlers by decorating a function with <a class="reference internal" href="../api/#flask.Flask.errorhandler" title="flask.Flask.errorhandler"><code class="xref py py-meth docutils literal notranslate">errorhandler()</code></a>. Or use <a class="reference internal" href="../api/#flask.Flask.register_error_handler" title="flask.Flask.register_error_handler"><code class="xref py py-meth docutils literal notranslate">register_error_handler()</code></a> to register the function later. Remember to set the error code when returning the response. <div class="highlight-python notranslate"><div class="highlight"><pre>@app.errorhandler(werkzeug.exceptions.BadRequest) def handle_bad_request(e): return 'bad request!', 400 # or, without the decorator app.register_error_handler(400, handle_bad_request) </pre></div> </div> <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">werkzeug.exceptions.HTTPException</code></a> subclasses like <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.BadRequest" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">BadRequest</code></a> and their HTTP codes are interchangeable when registering handlers. (<code class="docutils literal notranslate">BadRequest.code == 400</code>) Non-standard HTTP codes cannot be registered by code because they are not known by Werkzeug. Instead, define a subclass of <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-class docutils literal notranslate">HTTPException</code></a> with the appropriate code and register and raise that exception class. <div class="highlight-python notranslate"><div class="highlight"><pre>class InsufficientStorage(werkzeug.exceptions.HTTPException): code = 507 description = 'Not enough storage space.' app.register_error_handler(InsufficientStorage, handle_507) raise InsufficientStorage() </pre></div> </div> Handlers can be registered for any exception class, not just <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">HTTPException</code></a> subclasses or HTTP status codes. Handlers can be registered for a specific class, or for all subclasses of a parent class. </section> <section id="handling"> <h3>Handling<a class="headerlink" href="#handling" title="Link to this heading">¶</a></h3> When building a Flask application you will run into exceptions. If some part of your code breaks while handling a request (and you have no error handlers registered), a “500 Internal Server Error” (<a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.InternalServerError" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">InternalServerError</code></a>) will be returned by default. Similarly, “404 Not Found” (<a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.NotFound" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">NotFound</code></a>) error will occur if a request is sent to an unregistered route. If a route receives an unallowed request method, a “405 Method Not Allowed” (<a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.MethodNotAllowed" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">MethodNotAllowed</code></a>) will be raised. These are all subclasses of <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-class docutils literal notranslate">HTTPException</code></a> and are provided by default in Flask. Flask gives you the ability to raise any HTTP exception registered by Werkzeug. However, the default HTTP exceptions return simple exception pages. You might want to show custom error pages to the user when an error occurs. This can be done by registering error handlers. When Flask catches an exception while handling a request, it is first looked up by code. If no handler is registered for the code, Flask looks up the error by its class hierarchy; the most specific handler is chosen. If no handler is registered, <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-class docutils literal notranslate">HTTPException</code></a> subclasses show a generic message about their code, while other exceptions are converted to a generic “500 Internal Server Error”. For example, if an instance of <a class="reference external" href="https://docs.python.org/3/library/exceptions.html#ConnectionRefusedError" title="(in Python v3.13)"><code class="xref py py-exc docutils literal notranslate">ConnectionRefusedError</code></a> is raised, and a handler is registered for <a class="reference external" href="https://docs.python.org/3/library/exceptions.html#ConnectionError" title="(in Python v3.13)"><code class="xref py py-exc docutils literal notranslate">ConnectionError</code></a> and <a class="reference external" href="https://docs.python.org/3/library/exceptions.html#ConnectionRefusedError" title="(in Python v3.13)"><code class="xref py py-exc docutils literal notranslate">ConnectionRefusedError</code></a>, the more specific <a class="reference external" href="https://docs.python.org/3/library/exceptions.html#ConnectionRefusedError" title="(in Python v3.13)"><code class="xref py py-exc docutils literal notranslate">ConnectionRefusedError</code></a> handler is called with the exception instance to generate the response. Handlers registered on the blueprint take precedence over those registered globally on the application, assuming a blueprint is handling the request that raises the exception. However, the blueprint cannot handle 404 routing errors because the 404 occurs at the routing level before the blueprint can be determined. </section> <section id="generic-exception-handlers"> <h3>Generic Exception Handlers<a class="headerlink" href="#generic-exception-handlers" title="Link to this heading">¶</a></h3> It is possible to register error handlers for very generic base classes such as <code class="docutils literal notranslate">HTTPException</code> or even <code class="docutils literal notranslate">Exception</code>. However, be aware that these will catch more than you might expect. For example, an error handler for <code class="docutils literal notranslate">HTTPException</code> might be useful for turning the default HTML errors pages into JSON. However, this handler will trigger for things you don’t cause directly, such as 404 and 405 errors during routing. Be sure to craft your handler carefully so you don’t lose information about the HTTP error. <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import json from werkzeug.exceptions import HTTPException @app.errorhandler(HTTPException) def handle_exception(e): """Return JSON instead of HTML for HTTP errors.""" # start with the correct headers and status code from the error response = e.get_response() # replace the body with JSON response.data = json.dumps({ "code": e.code, "name": e.name, "description": e.description, }) response.content_type = "application/json" return response </pre></div> </div> An error handler for <code class="docutils literal notranslate">Exception</code> might seem useful for changing how all errors, even unhandled ones, are presented to the user. However, this is similar to doing <code class="docutils literal notranslate">except Exception:</code> in Python, it will capture all otherwise unhandled errors, including all HTTP status codes. In most cases it will be safer to register handlers for more specific exceptions. Since <code class="docutils literal notranslate">HTTPException</code> instances are valid WSGI responses, you could also pass them through directly. <div class="highlight-python notranslate"><div class="highlight"><pre>from werkzeug.exceptions import HTTPException @app.errorhandler(Exception) def handle_exception(e): # pass through HTTP errors if isinstance(e, HTTPException): return e # now you're handling non-HTTP exceptions only return render_template("500_generic.html", e=e), 500 </pre></div> </div> Error handlers still respect the exception class hierarchy. If you register handlers for both <code class="docutils literal notranslate">HTTPException</code> and <code class="docutils literal notranslate">Exception</code>, the <code class="docutils literal notranslate">Exception</code> handler will not handle <code class="docutils literal notranslate">HTTPException</code> subclasses because the <code class="docutils literal notranslate">HTTPException</code> handler is more specific. </section> <section id="unhandled-exceptions"> <h3>Unhandled Exceptions<a class="headerlink" href="#unhandled-exceptions" title="Link to this heading">¶</a></h3> When there is no error handler registered for an exception, a 500 Internal Server Error will be returned instead. See <a class="reference internal" href="../api/#flask.Flask.handle_exception" title="flask.Flask.handle_exception"><code class="xref py py-meth docutils literal notranslate">flask.Flask.handle_exception()</code></a> for information about this behavior. If there is an error handler registered for <code class="docutils literal notranslate">InternalServerError</code>, this will be invoked. As of Flask 1.1.0, this error handler will always be passed an instance of <code class="docutils literal notranslate">InternalServerError</code>, not the original unhandled error. The original error is available as <code class="docutils literal notranslate">e.original_exception</code>. An error handler for “500 Internal Server Error” will be passed uncaught exceptions in addition to explicit 500 errors. In debug mode, a handler for “500 Internal Server Error” will not be used. Instead, the interactive debugger will be shown. </section> </section> <section id="custom-error-pages"> <h2>Custom Error Pages<a class="headerlink" href="#custom-error-pages" title="Link to this heading">¶</a></h2> Sometimes when building a Flask application, you might want to raise a <a class="reference external" href="https://werkzeug.palletsprojects.com/en/stable/exceptions/#werkzeug.exceptions.HTTPException" title="(in Werkzeug v3.1.x)"><code class="xref py py-exc docutils literal notranslate">HTTPException</code></a> to signal to the user that something is wrong with the request. Fortunately, Flask comes with a handy <a class="reference internal" href="../api/#flask.abort" title="flask.abort"><code class="xref py py-func docutils literal notranslate">abort()</code></a> function that aborts a request with a HTTP error from werkzeug as desired. It will also provide a plain black and white error page for you with a basic description, but nothing fancy. Depending on the error code it is less or more likely for the user to actually see such an error. Consider the code below, we might have a user profile route, and if the user fails to pass a username we can raise a “400 Bad Request”. If the user passes a username and we can’t find it, we raise a “404 Not Found”. <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import abort, render_template, request # a username needs to be supplied in the query args # a successful request would be like /profile?username=jack @app.route("/profile") def user_profile(): username = request.arg.get("username") # if a username isn't supplied in the request, return a 400 bad request if username is None: abort(400) user = get_user(username=username) # if a user can't be found by their username, return 404 not found if user is None: abort(404) return render_template("profile.html", user=user) </pre></div> </div> Here is another example implementation for a “404 Page Not Found” exception: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import render_template @app.errorhandler(404) def page_not_found(e): # note that we set the 404 status explicitly return render_template('404.html'), 404 </pre></div> </div> When using <a class="reference internal" href="../patterns/appfactories/">Application Factories</a>: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import Flask, render_template def page_not_found(e): return render_template('404.html'), 404 def create_app(config_filename): app = Flask(__name__) app.register_error_handler(404, page_not_found) return app </pre></div> </div> An example template might be this: <div class="highlight-html+jinja notranslate"><div class="highlight"><pre>{% extends "layout.html" %} {% block title %}Page Not Found{% endblock %} {% block body %} <h1>Page Not Found</h1> <p>What you were looking for is just not there. <p><a href="{{ url_for('index') }}">go somewhere nice</a> {% endblock %} </pre></div> </div> <section id="further-examples"> <h3>Further Examples<a class="headerlink" href="#further-examples" title="Link to this heading">¶</a></h3> The above examples wouldn’t actually be an improvement on the default exception pages. We can create a custom 500.html template like this: <div class="highlight-html+jinja notranslate"><div class="highlight"><pre>{% extends "layout.html" %} {% block title %}Internal Server Error{% endblock %} {% block body %} <h1>Internal Server Error</h1> <p>Oops... we seem to have made a mistake, sorry!</p> <p><a href="{{ url_for('index') }}">Go somewhere nice instead</a> {% endblock %} </pre></div> </div> It can be implemented by rendering the template on “500 Internal Server Error”: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import render_template @app.errorhandler(500) def internal_server_error(e): # note that we set the 500 status explicitly return render_template('500.html'), 500 </pre></div> </div> When using <a class="reference internal" href="../patterns/appfactories/">Application Factories</a>: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import Flask, render_template def internal_server_error(e): return render_template('500.html'), 500 def create_app(): app = Flask(__name__) app.register_error_handler(500, internal_server_error) return app </pre></div> </div> When using <a class="reference internal" href="../blueprints/">Modular Applications with Blueprints</a>: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import Blueprint blog = Blueprint('blog', __name__) # as a decorator @blog.errorhandler(500) def internal_server_error(e): return render_template('500.html'), 500 # or with register_error_handler blog.register_error_handler(500, internal_server_error) </pre></div> </div> </section> </section> <section id="blueprint-error-handlers"> <h2>Blueprint Error Handlers<a class="headerlink" href="#blueprint-error-handlers" title="Link to this heading">¶</a></h2> In <a class="reference internal" href="../blueprints/">Modular Applications with Blueprints</a>, most error handlers will work as expected. However, there is a caveat concerning handlers for 404 and 405 exceptions. These error handlers are only invoked from an appropriate <code class="docutils literal notranslate">raise</code> statement or a call to <code class="docutils literal notranslate">abort</code> in another of the blueprint’s view functions; they are not invoked by, e.g., an invalid URL access. This is because the blueprint does not “own” a certain URL space, so the application instance has no way of knowing which blueprint error handler it should run if given an invalid URL. If you would like to execute different handling strategies for these errors based on URL prefixes, they may be defined at the application level using the <code class="docutils literal notranslate">request</code> proxy object. <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import jsonify, render_template # at the application level # not the blueprint level @app.errorhandler(404) def page_not_found(e): # if a request is in our blog URL space if request.path.startswith('/blog/'): # we return a custom blog 404 page return render_template("blog/404.html"), 404 else: # otherwise we return our generic site-wide 404 page return render_template("404.html"), 404 @app.errorhandler(405) def method_not_allowed(e): # if a request has the wrong method to our API if request.path.startswith('/api/'): # we return a json saying so return jsonify(message="Method Not Allowed"), 405 else: # otherwise we return a generic site-wide 405 page return render_template("405.html"), 405 </pre></div> </div> </section> <section id="returning-api-errors-as-json"> <h2>Returning API Errors as JSON<a class="headerlink" href="#returning-api-errors-as-json" title="Link to this heading">¶</a></h2> When building APIs in Flask, some developers realise that the built-in exceptions are not expressive enough for APIs and that the content type of text/html they are emitting is not very useful for API consumers. Using the same techniques as above and <a class="reference internal" href="../api/#flask.json.jsonify" title="flask.json.jsonify"><code class="xref py py-func docutils literal notranslate">jsonify()</code></a> we can return JSON responses to API errors. <a class="reference internal" href="../api/#flask.abort" title="flask.abort"><code class="xref py py-func docutils literal notranslate">abort()</code></a> is called with a <code class="docutils literal notranslate">description</code> parameter. The error handler will use that as the JSON error message, and set the status code to 404. <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import abort, jsonify @app.errorhandler(404) def resource_not_found(e): return jsonify(error=str(e)), 404 @app.route("/cheese") def get_one_cheese(): resource = get_resource() if resource is None: abort(404, description="Resource not found") return jsonify(resource) </pre></div> </div> We can also create custom exception classes. For instance, we can introduce a new custom exception for an API that can take a proper human readable message, a status code for the error and some optional payload to give more context for the error. This is a simple example: <div class="highlight-python notranslate"><div class="highlight"><pre>from flask import jsonify, request class InvalidAPIUsage(Exception): status_code = 400 def __init__(self, message, status_code=None, payload=None): super().__init__() self.message = message if status_code is not None: self.status_code = status_code self.payload = payload def to_dict(self): rv = dict(self.payload or ()) rv['message'] = self.message return rv @app.errorhandler(InvalidAPIUsage) def invalid_api_usage(e): return jsonify(e.to_dict()), e.status_code # an API app route for getting user information # a correct request might be /api/user?user_id=420 @app.route("/api/user") def user_api(user_id): user_id = request.arg.get("user_id") if not user_id: raise InvalidAPIUsage("No user id provided!") user = get_user(user_id=user_id) if not user: raise InvalidAPIUsage("No such user!", status_code=404) return jsonify(user.to_dict()) </pre></div> </div> A view can now raise that exception with an error message. Additionally some extra payload can be provided as a dictionary through the <code class="code docutils literal notranslate">payload</code> parameter. </section> <section id="logging"> <h2>Logging<a class="headerlink" href="#logging" title="Link to this heading">¶</a></h2> See <a class="reference internal" href="../logging/">Logging</a> for information about how to log exceptions, such as by emailing them to admins. </section> <section id="debugging"> <h2>Debugging<a class="headerlink" href="#debugging" title="Link to this heading">¶</a></h2> See <a class="reference internal" href="../debugging/">Debugging Application Errors</a> for information about how to debug errors in development and production. </section> </section> <div class="clearer"></div> </div> </div> </div> <div class="sphinxsidebar" role="navigation" aria-label="Main"> <div class="sphinxsidebarwrapper"> <a href="../"> <img class="logo" src="../_static/flask-vertical.png" alt="Logo of Flask"/> </a> <h3>Contents</h3> <ul> <li><a class="reference internal" href="#">Handling Application Errors</a><ul> <li><a class="reference internal" href="#error-logging-tools">Error Logging Tools</a></li> <li><a class="reference internal" href="#error-handlers">Error Handlers</a><ul> <li><a class="reference internal" href="#registering">Registering</a></li> <li><a class="reference internal" href="#handling">Handling</a></li> <li><a class="reference internal" href="#generic-exception-handlers">Generic Exception Handlers</a></li> <li><a class="reference internal" href="#unhandled-exceptions">Unhandled Exceptions</a></li> </ul> </li> <li><a class="reference internal" href="#custom-error-pages">Custom Error Pages</a><ul> <li><a class="reference internal" href="#further-examples">Further Examples</a></li> </ul> </li> <li><a class="reference internal" href="#blueprint-error-handlers">Blueprint Error Handlers</a></li> <li><a class="reference internal" href="#returning-api-errors-as-json">Returning API Errors as JSON</a></li> <li><a class="reference internal" href="#logging">Logging</a></li> <li><a class="reference internal" href="#debugging">Debugging</a></li> </ul> </li> </ul> <h3>Navigation</h3> <ul> <li><a href="../">Overview</a> <ul> <li>Previous: <a href="../testing/" title="previous chapter">Testing Flask Applications</a> <li>Next: <a href="../debugging/" title="next chapter">Debugging Application Errors</a> </ul> </li> </ul> <search id="searchbox" style="display: none" role="search"> <h3 id="searchlabel">Quick search</h3> <div class="searchformwrapper"> <form class="search" action="../search/" method="get"> <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/> <input type="submit" value="Go" /> </form> </div> </search> <script>document.getElementById('searchbox').style.display = "block"</script><div id="ethical-ad-placement"></div> </div> </div> <div class="clearer"></div> </div> <div class="footer" role="contentinfo"> © Copyright 2010 Pallets. Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 8.1.3. </div> </body> </html>