Merge pull request #1942 from jmsdvl/fix-1935

clarify blueprint 404 error handling in docs

docs/blueprints.rst

@@ -177,11 +177,11 @@ the `template_folder` parameter to the :class:`Blueprint` constructor::
     admin = Blueprint('admin', __name__, template_folder='templates')
 
 For static files, the path can be absolute or relative to the blueprint
-resource folder.  
+resource folder.
 
-The template folder is added to the search path of templates but with a lower 
-priority than the actual application's template folder. That way you can 
-easily override templates that a blueprint provides in the actual application. 
+The template folder is added to the search path of templates but with a lower
+priority than the actual application's template folder. That way you can
+easily override templates that a blueprint provides in the actual application.
 This also means that if you don't want a blueprint template to be accidentally
 overridden, make sure that no other blueprint or actual application template
 has the same relative path. When multiple blueprints provide the same relative
@@ -194,7 +194,7 @@ want to render the template ``'admin/index.html'`` and you have provided
 this: :file:`yourapplication/admin/templates/admin/index.html`. The reason
 for the extra ``admin`` folder is to avoid getting our template overridden
 by a template named ``index.html`` in the actual application template
-folder.  
+folder.
 
 To further reiterate this: if you have a blueprint named ``admin`` and you
 want to render a template called :file:`index.html` which is specific to this
@@ -245,4 +245,22 @@ Here is an example for a "404 Page Not Found" exception::
     def page_not_found(e):
         return render_template('pages/404.html')
 
+Most errorhandlers will simply work as expected; however, there is a caveat
+concerning handlers for 404 and 405 exceptions.  These errorhandlers 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.  This is because the blueprint does not "own" a certain URL space, so
+the application instance has no way of knowing which blueprint errorhandler 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 ``request`` proxy object::
+
+    @app.errorhandler(404)
+    @app.errorhandler(405)
+    def _handle_api_error(ex):
+        if request.path.startswith('/api/'):
+            return jsonify_error(ex)
+        else:
+            return ex
+
 More information on error handling see :ref:`errorpages`.