[5.5] Add handleExceptions

[sileence]

This method allows to deactivate the exception handling except for the given exceptions, that way, continuing with: #20724 I can have a test like:

        $this->handleValidationException()->post('profile', [
            'twitter' => '@{sileence}'
        ])
        ->assertSessionHasErrors('twitter');

And if an exception is thrown (other than a validation exception) then I will get the error in the console.

This way it is possible to get the best of both worlds?

Going further maybe I could add a handleExceptedException to throw an exception if the expected exception is not thrown (PHPUnit style)?

Or have some kind of wrapper like:

        $this->expectValidationErrors(['twitter'], function () {
            $this->post('profile', [
                'twitter' => '@{sileence}'
            ]);
        });

[taylorotwell]

It feels like you are going to great lengths to simply avoid writing $response->assertStatus(200) which would have solved your problem in the first place?

[sileence]

@taylorotwell well, 200, 422, 302.... So it can be confusing. But what I really don't like is having to go back to the test and type $this->withoutExceptionHandling() just to "uncover" the error. This idea or something similar could give more control over what exception is expected to be handled and allow faster debugging of unexpected exceptions.

[deleugpn]

I use the exception logger to uncover the error.

[sileence]

@deleugpn exactly, but that slows you down, and that's what Adam was trying to solve in the first place.

[sileence]

Now with some tests you do need to have the exception handling turned on. What I'm proposing is: ok, let's turn it on but only for the specific exceptions I want the framework to handle for me. Throw everything else.

[deleugpn]

Personally I don't agree with your statement because this is somewhat related to preference. I prefer the logger over seeing a full stack trace in a command line interface.

That said, I can see you want a behavior that is slightly different than blunt withoutExceptionHandler (and the Framework doesn't have that now). This is a second subject: you'll have to carefully know what you're doing to be able to know which exceptions you want to bypass or not.

My suggestion: propose a PR where you only add the except parameter (which is more or less what you're missing) to the withoutExceptionHandler(). Make it optional and don't assume everyone wants to do that for ValidationException. Let each developer choose what they want.
You can even go one step further and declare a protected $handleExceptions = [] that we can override in the TestCase.

I think this could make everyone happy.

[sileence]

@deleugpn I like the idea of the property, but that could also be implemented by the user.

The handleValidationException was a proof of concept. It could be removed. The important method is handleExceptions(array $exceptions).