[ENHANCEMENT]: Refactor Exception Handling to Use specific Exception Types for Better Error differentiation.

[jessevz]

Description

Currently the project only makes use of HTException as a very general exception for all error cases. This makes it challenging to handle different errors appropriately. Especially if we want to adhere to the JSON API standard it is helpful if more specific Exceptions get throwed so that the API can catch these specific exceptions and respond with appropriate HTTP status codes and responses.

Tasks:

• Define and implement specific exception classes for common error scenario ex: conflict, field missing ....
• Refactor service and logic layers to throw the new exceptions
• Update the new API to catch specific exceptions and return the proper HTTP responses
• Add documentation for the new exception handling
• should fix #1251

[gluafamichl]

We usually define a base exception class, e.g. ApplicationException and derive all other exceptions from this base class, lets say DBFieldErrorException, InvalidTypeException and so on. Each exception contains its own error message and/or a status code.

The surrounding API does not know, which exact exceptions could be thrown, it always catches ApplicationExcetion, but gets the error message and error code from the real exception class.

Maybe we could define a similar exception system, just share your thoughts ;-)

[jessevz]

Exceptions have been reworked in #1266. What is still left is to refactor all old HTexceptions into the new way off exceptions