PoC: Implemented Repository to REST Exception converters

[alongosz]

Question	Answer
JIRA issue	n/a
Type	improvement
Target Ibexa version	v4.6
BC breaks	no

Ibexa REST defines a few of its own Exception classes and API Exception wrapper classes. In order for an API Exception to be rendered correctly as a response, it needs to be either wrapped with REST Exception which has its own Visitor or actually have dedicated Visitor. If we look at ./src/bundle/Resources/config/value_object_visitors.yml we will find a mix of those approaches.

Instead of trying to cover both REST and Repository API exceptions with one or two separate visitors, I suggest a new idea: Repository Exception converter which would map a Repository Exception into its REST counterpart.

As an example, ContentFieldValidationExceptionConverter, has been implemented to properly map Repository API ContentFieldValidationException to REST ContentFieldValidationException. This allows the following simplification of REST Controllers:

Before:

public function updateCompanyAction(
    APICompany $company,
    RestCompanyUpdateStruct $companyUpdateStruct
): Company {
    try {
        $updatedCompany = $this->companyService->updateCompany(
            $company,
            $companyUpdateStruct->companyUpdateStruct
        );

        return new RestCompany($updatedCompany);
    } catch (APIContentFieldValidationException $e) {
        throw new RestContentFieldValidationException($e);
    }
}

After:

public function updateCompanyAction(
    APICompany $company,
    RestCompanyUpdateStruct $companyUpdateStruct
): Company {
    $updatedCompany = $this->companyService->updateCompany(
        $company,
        $companyUpdateStruct->companyUpdateStruct
    );

    return new RestCompany($updatedCompany);
}

Paths to explore

• Maybe introduce more generic extension point that would try to find converter for any non-REST exception, but there might be too much ambiguity to handle that.

TODO

• Cover all RepositoryExceptions with proper Converters
• Remove DIC and visitor logic that now would be handled by Converters

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[adamwojs]

+1 from conceptual point of view