feat: Added "status" and "code" to errors

[kailash360]

I added status and code to the errors.

Closes #337

Changes

• Adds status and code to the different exceptions
• New exception types added as constant

Flags

N/A

Screenshots or Video

N/A

Related Issues

• Issue Add code and status properties to produced errors #337
• Pull Request N/A

Author Checklist

• Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
• Vital features and changes captured in unit and/or integration tests
• Commits messages follow AP format
• Extend the documentation, if necessary
• Merging to main from fork:branchname

[kailash360]

@mttrbrts

I have created this PR to add status and code in the exceptions so that they can be accessed easily.

[mttrbrts]

This is a great start, thank you @kailash360.

I'd like to start a discussion about the design of the error codes before we fix them. For example, I think that there are semantic groups that we should use to categorise the similar codes (e.g. taking inspiration from the HTTP Status codes, e.g. https://www.npmjs.com/package/http-status-codes).

[mttrbrts]

What is the benefit here of splitting the code and status into two parameters? Would one suffice?

[kailash360]

We can surely reduce it to the {code,status} object that we want and pass it directly, instead of spreading it. This approach was made keeping in mind that there wasn't any grouping of errors defined explicitly. So the user can perhaps use a separate error code and status to define in an exception. I will reduce it to a single object.

[mttrbrts]

This is a breaking change, unfortunately. Is there a way to make this backwards compatible? If not, we should target the v4.0 branch

[kailash360]

Alright, will rebase the PR to v4.0

[kailash360]

This is a great start, thank you @kailash360.

I'd like to start a discussion about the design of the error codes before we fix them. For example, I think that there are semantic groups that we should use to categorise the similar codes (e.g. taking inspiration from the HTTP Status codes, e.g. https://www.npmjs.com/package/http-status-codes).

Considering the HTTP Status codes, we can obviously define our own error codes. I referred to this resource explaining the context of numbering the HTTP Status codes. On a higher ground, they are categorized based on the nature or aspect of the HTTP request. In our case, we need to define the depth that we need to cover.

For example, we can define status codes for TypeNotFoundException or SecurityException and use them anytime we get these errors. But for a detailed explanation, we can also define the family of TypeNotFoundException errors as 3xx and specify the error code for each of the sub-types, and follow this for the other exceptions as well. I personally feel the latter approach will add a big overhead.

If you recommend, I can group the existing exceptions in the below format:

Syntax Errors
Starts with 3 and follows 3x format

• 31 TypeNotFoundException
• 32 ValidationException
• 33 MetaModelException

Semantic Errors
Starts with 4 and follows 4x format

• 41 BaseFileException
• 42 IllegalModelException
• 43 SecurityException

Let me know if this sounds good to proceed.

[mttrbrts]

Yes, this is the right direction. I recommend that we discuss this design live on a Working Group call. They run weekly at 8am EST

Also, can you rebase you PR on top of the v4.0.0 branch, please? If you look at the commit log, your PR also includes lots of unrelated changes.

[mttrbrts]

@kailash360

We reviewed this change in the working group call on 13 March (https://vimeo.com/922895729). The consensus was that a previous change has already addressed this issue sufficiently by adding types to Errors. We haven't solved the categorisation problem but we should first come up with a design for that in an issue, before writing code.

I'm sorry for any wasted time here on your part.