From 6a1c9338cf02ca393c01f0e8a8b0794f7df31eb8 Mon Sep 17 00:00:00 2001 From: soyuka Date: Thu, 11 Jun 2026 15:05:32 +0200 Subject: [PATCH 1/2] docs(errors): warn that exception_to_status is not merged with defaults Declaring a custom exception_to_status mapping replaces the built-in one entirely rather than merging. Omitting the default handlers makes serializer exceptions (non-existing relation item, invalid backed enum) fall through to the 500 fallback instead of 400. Closes #6116 --- core/errors.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/core/errors.md b/core/errors.md index 30b25280c47..f691a4aeec6 100644 --- a/core/errors.md +++ b/core/errors.md @@ -164,6 +164,14 @@ return [ ]; ``` +> [!WARNING] +> The `exception_to_status` configuration is **not merged** with the defaults: as soon as you declare +> your own mapping, it replaces the built-in one entirely. If you omit the default handlers shown +> above, exceptions that were previously mapped to `400` (such as the +> `Symfony\Component\Serializer\Exception\ExceptionInterface` thrown when denormalizing a relation to a +> non-existing item, or an invalid backed enum value) will fall through to the `500` fallback. Always +> keep the default lines and append your custom mappings to them. + Any type of `Exception` can be thrown, API Platform will convert it to a Symfony's `HttpException` (note that it means the exception will be flattened and lose all of its custom properties). The framework also takes care of serializing the error description according to the request format. For From f146a3ece127f617e1f010fa3c199ead8ffe36c3 Mon Sep 17 00:00:00 2001 From: soyuka Date: Thu, 11 Jun 2026 15:20:36 +0200 Subject: [PATCH 2/2] docs(errors): apply prettier formatting --- core/errors.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/core/errors.md b/core/errors.md index f691a4aeec6..2660dcd5d4f 100644 --- a/core/errors.md +++ b/core/errors.md @@ -164,13 +164,12 @@ return [ ]; ``` -> [!WARNING] -> The `exception_to_status` configuration is **not merged** with the defaults: as soon as you declare -> your own mapping, it replaces the built-in one entirely. If you omit the default handlers shown -> above, exceptions that were previously mapped to `400` (such as the -> `Symfony\Component\Serializer\Exception\ExceptionInterface` thrown when denormalizing a relation to a -> non-existing item, or an invalid backed enum value) will fall through to the `500` fallback. Always -> keep the default lines and append your custom mappings to them. +> [!WARNING] The `exception_to_status` configuration is **not merged** with the defaults: as soon as +> you declare your own mapping, it replaces the built-in one entirely. If you omit the default +> handlers shown above, exceptions that were previously mapped to `400` (such as the +> `Symfony\Component\Serializer\Exception\ExceptionInterface` thrown when denormalizing a relation +> to a non-existing item, or an invalid backed enum value) will fall through to the `500` fallback. +> Always keep the default lines and append your custom mappings to them. Any type of `Exception` can be thrown, API Platform will convert it to a Symfony's `HttpException` (note that it means the exception will be flattened and lose all of its custom properties). The