In some of routes for our Api-Platform project, exceptions are thrown for some common error conditions.
E.g. while calling POST /orders, NewOrderHandler can throw either of this two if appropriate:
NotEnoughStockNotEnoughCredit
All these exceptions belong to a DomainException hierarchy.
These exceptions are correctly converted to status code 400 on the response by using the exception_to_status configuration, and the response includes the appropriate error message. So far so good.
exception_to_status:
App\Order\NotEnoughStock: !php/const Symfony\Component\HttpFoundation\Response::HTTP_BAD_REQUEST
App\Order\NotEnoughCredit: !php/const Symfony\Component\HttpFoundation\Response::HTTP_BAD_REQUEST
The only problem is that the exception is still logged as a CRITICAL error, being treated as an "uncaught exception". This gets logged even in production.
I would have expected that by being converted to a correct status code (e.g. !== 500) these exceptions would be treated as "handled", and thus would not pollute the logs.
Throwing exceptions from the handler is convenient, because it helps deal with transactionality and automatically generates the appropriate error response message. It works for web and console.
Shouldn't these transactions be treated as handled? Is it necessary to create another exception listener to deal with this? And if creating an exception listener, how to do it so it doesn't interfere with Api-Platform error normalization?