docs: refactor exception usage (#3823)

docs/usage/exceptions.rst

@@ -2,20 +2,20 @@ Exceptions and exception handling
 =================================
 
 Litestar define a base exception called :class:`LitestarException <litestar.exceptions.LitestarException>` which serves
-as a basis to all other exceptions.
+as a base class for all other exceptions, see :mod:`API Reference <litestar.exceptions>`.
 
-In general, Litestar will raise two types of exceptions:
+In general, Litestar has two scenarios for exception handling:
 
-- Exceptions that arise during application init, which fall
-- Exceptions that are raised as part of the normal application flow, i.e.
-  exceptions in route handlers, dependencies, and middleware, that should be serialized in some fashion.
+- Exceptions that are raised during application configuration, startup, and initialization, which are handled like regular Python exceptions
+- Exceptions that are raised as part of the request handling, i.e.
+  exceptions in route handlers, dependencies, and middleware, that should be returned as a response to the end user
 
 Configuration Exceptions
 ------------------------
 
 For missing extra dependencies, Litestar will raise either
 :class:`MissingDependencyException <litestar.exceptions.MissingDependencyException>`. For example, if you try to use the
-:doc:`SQLAlchemyPlugin </usage/databases/sqlalchemy/plugins/index>` without having SQLAlchemy installed, this will be raised when you
+:ref:`SQLAlchemyPlugin <plugins>` without having SQLAlchemy installed, this will be raised when you
 start the application.
 
 For other configuration issues, Litestar will raise
@@ -25,8 +25,8 @@ issue.
 Application Exceptions
 ----------------------
 
-For application exceptions, Litestar uses the class :class:`HTTPException <.exceptions.http_exceptions.HTTPException>`,
-which inherits from :class:`LitestarException <.exceptions.LitestarException>`. This exception will be serialized
+For application exceptions, Litestar uses the class :class:`~litestar.exceptions.http_exceptions.HTTPException`,
+which inherits from :class:`~litestar.exceptions.LitestarException`. This exception will be serialized
 into a JSON response of the following schema:
 
 .. code-block:: json
@@ -37,10 +37,10 @@ into a JSON response of the following schema:
      "extra": {}
    }
 
-Litestar also offers several pre-configured exception subclasses with pre-set error codes that you can use, such as:
+Litestar also offers several pre-configured ``HTTPException`` subclasses with pre-set error codes that you can use, such as:
 
 
-.. py:currentmodule:: litestar.exceptions.http_exceptions
+.. :currentmodule:: litestar.exceptions.http_exceptions
 
 +----------------------------------------+-------------+------------------------------------------+
 | Exception                              | Status code | Description                              |
@@ -49,26 +49,30 @@ Litestar also offers several pre-configured exception subclasses with pre-set er
 +----------------------------------------+-------------+------------------------------------------+
 | :class:`ValidationException`           | 400         | Raised when validation or parsing failed |
 +----------------------------------------+-------------+------------------------------------------+
-| :class:`NotFoundException`             | 404         | HTTP status code 404                     |
-+----------------------------------------+-------------+------------------------------------------+
 | :class:`NotAuthorizedException`        | 401         | HTTP status code 401                     |
 +----------------------------------------+-------------+------------------------------------------+
 | :class:`PermissionDeniedException`     | 403         | HTTP status code 403                     |
 +----------------------------------------+-------------+------------------------------------------+
+| :class:`NotFoundException`             | 404         | HTTP status code 404                     |
++----------------------------------------+-------------+------------------------------------------+
 | :class:`InternalServerException`       | 500         | HTTP status code 500                     |
 +----------------------------------------+-------------+------------------------------------------+
 | :class:`ServiceUnavailableException`   | 503         | HTTP status code 503                     |
 +----------------------------------------+-------------+------------------------------------------+
 
-When a value fails ``pydantic`` validation, the result will be a :class:`ValidationException` with the ``extra`` key set to the
-pydantic validation errors. Thus, this data will be made available for the API consumers by default.
+.. :currentmodule:: None
+
+When a value fails validation, the result will be a :class:`~litestar.exceptions.http_exceptions.ValidationException` with the ``extra`` key set to the validation error message.
+
+.. warning:: All validation error messages will be made available for the API consumers by default.
+    If this is not your intent, adjust the exception contents.
 
 
 Exception handling
 ------------------
 
 Litestar handles all errors by default by transforming them into **JSON responses**. If the errors are **instances of**
-:class:`HTTPException`, the responses will include the appropriate ``status_code``.
+:class:`~litestar.exceptions.http_exceptions.HTTPException`, the responses will include the appropriate ``status_code``.
 Otherwise, the responses will default to ``500 - "Internal Server Error"``.
 
 You can customize exception handling by passing a dictionary, mapping either status codes
@@ -89,14 +93,6 @@ exceptions that inherit from ``HTTPException``. You could of course be more gran
 The choice whether to use a single function that has switching logic inside it, or multiple functions depends on your
 specific needs.
 
-While it does not make much sense to have different functions with a top-level exception handling,
-Litestar supports defining exception handlers on all layers of the app, with the lower layers overriding layer above
-them. In the following example, the exception handler for the route handler function will only handle
-the ``ValidationException`` occurring within that route handler:
-
-.. literalinclude:: /examples/exceptions/layered_handlers.py
-    :language: python
-
 
 Exception handling layers
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -116,3 +112,10 @@ As a result of the above structure, the exceptions raised by the ASGI Router its
 and ``405 Method Not Allowed`` are handled only by exception handlers defined on the app layer. Thus, if you want to affect
 these exceptions, you will need to pass the exception handlers for them to the Litestar constructor and cannot use other
 layers for this purpose.
+
+Litestar supports defining exception handlers on all layers of the app, with the lower layers overriding layer above
+them. In the following example, the exception handler for the route handler function will only handle
+the ``ValidationException`` occurring within that route handler:
+
+.. literalinclude:: /examples/exceptions/layered_handlers.py
+    :language: python

docs/usage/plugins/index.rst

@@ -1,3 +1,5 @@
+.. _plugins:
+
 =======
 Plugins
 =======