feat(administration service): change error handling

[AnuragNagpure]

Description

Implement new error handling in below mentioned Administrative Services Controller and respective Business Logic
CompanyDataController
DocumentsController
IdentityProviderController
NetworkController
PartnerNetworkController
RegistrationController
RegistrationStatusController
ServiceAccountController
SubscriptionConfigurationController

All supported exceptions need to get transferred to the new error response method.

Why

Implement for all controller and its business logic the new error handling - see details regarding the structure below.

{
"type": "string",
"title": "string",
"status": 0,
"errors": {
"additionalProp1": [
"string"
],
"additionalProp2": [
"string"
],
"additionalProp3": [
"string"
]
},
"errorId": "string",
"details": [
{
"errorCode": "string",
"type": "string",
"message": "string",
"parameters": [
{
"name": "string",
"value": "string"
}
]
}
]
}

Issue

#1183

Checklist

Please delete options that are not relevant.

• I have followed the contributing guidelines
• I have performed a self-review of my own code
• I have successfully tested my changes locally
• I have added tests that prove my changes work
• I have checked that new and existing tests pass locally with my changes
• I have commented my code, particularly in hard-to-understand areas

[Phil91]

In my opinion it would make sense to add a DefaultErrorMessageContainer to the Framework.ErrorHandling -> ErrorHandling.

This could include a ENTITY_NOT_EXIST with the following error message: {entityType} {entityId} does not exist
It could include NULL_NOT_ALLOWED with the following error message: {propertyName} must not be null
It could include VALUE_EXPECTED with the following error message: value for {headerProviderAlias} expected
It could include ENTITY_ALREADY_EXISTS with the following error message: {entityType} {entityId} already exist

maybe there are a few more which can be aligned

[ntruchsess]

In my opinion it would make sense to add a DefaultErrorMessageContainer to the Framework.ErrorHandling -> ErrorHandling.

This could include a ENTITY_NOT_EXIST with the following error message: {entityType} {entityId} does not exist It could include NULL_NOT_ALLOWED with the following error message: {propertyName} must not be null It could include VALUE_EXPECTED with the following error message: value for {headerProviderAlias} expected It could include ENTITY_ALREADY_EXISTS with the following error message: {entityType} {entityId} already exist

maybe there are a few more which can be aligned

@Phil91 : Certainly having generic error-types would reduce the amount of code in the backend. But the idea is that the frontend can (optionally) do more than just pop-up an internationalized error-message. If appropriate it could precisely link to error-specific information that might help the user to resolve the issue. It's also the plan to implement a unified error-handling that any fe-code getting a standard-error from the backend just would delegate to. If error-codes were generic the fe would need to pass additional context-information to the error-handler. As a result the reduced amount of code in the backend would result in higher complexity in the frontend.

see my comment #1192 (comment)

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.9% Duplication on New Code

See analysis details on SonarQube Cloud

[Phil91]

In my opinion it would make sense to add a DefaultErrorMessageContainer to the Framework.ErrorHandling -> ErrorHandling.
This could include a ENTITY_NOT_EXIST with the following error message: {entityType} {entityId} does not exist It could include NULL_NOT_ALLOWED with the following error message: {propertyName} must not be null It could include VALUE_EXPECTED with the following error message: value for {headerProviderAlias} expected It could include ENTITY_ALREADY_EXISTS with the following error message: {entityType} {entityId} already exist
maybe there are a few more which can be aligned

@Phil91 : Certainly having generic error-types would reduce the amount of code in the backend. But the idea is that the frontend can (optionally) do more than just pop-up an internationalized error-message. If appropriate it could precisely link to error-specific information that might help the user to resolve the issue. It's also the plan to implement a unified error-handling that any fe-code getting a standard-error from the backend just would delegate to. If error-codes were generic the fe would need to pass additional context-information to the error-handler. As a result the reduced amount of code in the backend would result in higher complexity in the frontend.

@ntruchsess okay got the point, I will do a rereview. I think we can merge the pr after that.