there is a big difference here. RequestExceptionInterface has a very specific behavior. Those exceptions will be turned into specific 4xx status code for the response instead of being reported as bugs in the code.
This is valid for the InputBag where the invalid data is provided by user input. But for generic ParameterBag usages, we explicitly don't want that behavior as the invalid data would correspond to a bug in the code, not to a bad input.

So -1 for that.

However, the InputBag should override the new methods to throw a BadRequestException when there is an unexpected input value, as done for other methods (see getEnum for instance, which is implemented properly).

there is a big difference here. RequestExceptionInterface has a very specific behavior. Those exceptions will be turned into specific 4xx status code for the response instead of being reported as bugs in the code. This is valid for the InputBag where the invalid data is provided by user input. But for generic ParameterBag usages, we explicitly don't want that behavior as the invalid data would correspond to a bug in the code, not to a bad input.

So -1 for that.

Isn't the ParameterBag coming from the request too ?
I'm only using it with

$request->attributes

Could it be still possible to throw a Symfony-scoped exception rather than the native one ?
This is useful:

• In order to do custom catch
• When using static analysis and you want to track some exception and exclude others

@VincentLanglet $request->request, $request->query and $request->cookies are using the InputBag child class.

ParameterBag is used directly (instead of a specialized child class) only for $request->attributes. But attributes are not storing user input. They can only be set in the code.

there is a big difference here. RequestExceptionInterface has a very specific behavior. Those exceptions will be turned into specific 4xx status code for the response instead of being reported as bugs in the code. This is valid for the InputBag where the invalid data is provided by user input. But for generic ParameterBag usages, we explicitly don't want that behavior as the invalid data would correspond to a bug in the code, not to a bad input.

If so, the SessionNotFound shouldn't implement RequestExceptionInterface, it extending LogicException which mean it's more a developper bug than something wrong with the user request. It's even explained in the phpdoc it's thrown in the case: "attempt to read a session outside a request context (ie. cli script)."

I don't see a reason for a different behavior for SessionNotFound and for wrong data in ParameterBag then.

But I'm less concern about which exceptions/interface used. My main goal would be to scope the exception thrown, would you be ok with this @stof ? Then we'll have to decide

• If we use an existing exception/interface
• Introduce a new one (and maybe try to migrate some other exceptions, in a BC way).

However, the InputBag should override the new methods to throw a BadRequestException when there is an unexpected input value, as done for other methods (see getEnum for instance, which is implemented properly).

There is some indirection but that's the case, all is fine in InputBag to me.

SessionNotFound shouldn't implement RequestExceptionInterface

Looks like you might be right. Unless someone has an argument to keep the interface (other than BC I mean?)

goal would be to scope the exception thrown

What's your motivation for this goal? Any real-world use case that requires such discrimination for ParameterBag?

SessionNotFound shouldn't implement RequestExceptionInterface

Looks like you might be right. Unless someone has an argument to keep the interface (other than BC I mean?)

Isn't the BC argument a blocking point ?

goal would be to scope the exception thrown

What's your motivation for this goal? Any real-world use case that requires such discrimination for ParameterBag?

Kinda the same than #49881

It could be usful to do

try {
   // do things which play with the ParameterBag
} catch (SymfonException) {
    // things
} catch (...) {
   // things
}

But my main usage for scoped SymfonyException are the PHPStan analysis.
https://phpstan.org/blog/bring-your-exceptions-under-control

This setup enforce developer to try/catch all the exception thrown (except the excluded exception). For instance a general config would be to exclude LogicException, some other exceptions and ask to catch all other RuntimeException.
When library are scoping the exception, it's possible to do:

parameters:
	exceptions:
		checkedExceptionClasses:
			- 'Symfony\Component\Foo\BarException' # Will ignore those exceptions and child ones

which allow to write

$request->attribute->getString('_route');

without the need to catch the exception.
(But maybe It's my own wrong understanding of this exception and it's very recommend to catch such exception).

An example can be found here, in the own config file of the phpstan-src repository:
https://github.com/phpstan/phpstan-src/blob/1.11.x/build/phpstan.neon#L46

When they are not scoped, doing

parameters:
	exceptions:
		checkedExceptionClasses:
			- '\UnexpectedValue'

will exclude far more exception than wanted.

Then we should consider adding UnexpectedValueException to HttpFoundation instead. @stof WDYT?

Closing so keep the discussion relevant to the original PR. Please follow up in a new PR.