How would that work with the exception mapping already handled ? Would there not be conflicts / priority troubles there ?

How would that work with the exception mapping already handled ? Would there not be conflicts / priority troubles there ?

Parent classes are prioritized first, starting from the immediate parent first. Then, interfaces are processed, according to the order ofclass_implements(). There should be no BC break.

If i was not precise enough, i was making allusion to the framework exception map that already exists and... map classes or interfaces to HTTP status / Log level :https://symfony.com/doc/current/reference/configuration/framework.html#exceptions

I just find a bit odd that those two implementations both coexists in theErrorListener (one before and one after)

foreach ($this->exceptionsMappingas$class =>$config) {if (!$throwableinstanceof$class || !$config['status_code']) {continue;    }if (!$throwableinstanceof HttpExceptionInterface ||$throwable->getStatusCode() !==$config['status_code']) {$headers =$throwableinstanceof HttpExceptionInterface ?$throwable->getHeaders() : [];$throwable =newHttpException($config['status_code'],$throwable->getMessage(),$throwable,$headers);$event->setThrowable($throwable);    }break;}

If i was not precise enough, i was making allusion to the framework exception map that already exists and... map classes or interfaces to HTTP status / Log level :https://symfony.com/doc/current/reference/configuration/framework.html#exceptions

Yes, doing it from the configuration is the traditional way to do it before 6.3, and it is still working as intended.

https://symfony.com/blog/new-in-symfony-6-3-http-exception-attributes

Looking at the implementation, I think this might be too unusual - ie unexpected. The relationship is unnatural to me.

Why don't you leverageHttpExceptionInterface instead?

Looking at the implementation, I think this might be too unusual - ie unexpected. The relationship is unnatural to me.

Why don't you leverageHttpExceptionInterface instead?

That would require my domain model to depend on HttpKernel.

Without this change, I could still do it usingconfig/packages/exceptions.yaml which works with interfaces. But I don't see why it should work usingconfig/packages/exceptions.yaml but should not work with attributes.

Added more background information in the PR description.

Thank you@priyadi.