Add custom exceptions and exception middleware

[MaximilianRau04]

Currently, the backend mainly throws IllegalArgumentException for errors. We need custom exception classes and a centralized exception middleware to provide clearer error handling and consistent API responses.

You can orient yourself on the Vault Web Repo backend.

[msrajput08]

I'd like to work on this issue.
I plan to introduce custom exception classes and a centralized exception handler
similar to the Vault Web backend.

[msrajput08]

Hi maintainers 👋

I tried setting up the project locally and ran into a few test/build issues that were blocking further work on centralized exception handling.

I’ve addressed these issues and submitted Pull Request #60, which fixes the CI/test failures so the project builds successfully in a clean environment.
Kindly review the PR when you get a chance.

Before proceeding further with centralized exception handling, I wanted to confirm a few things:

Should IllegalArgumentException be fully replaced with custom exceptions?

Is there a preferred structure or naming convention for new exceptions?

Should the GlobalExceptionHandler map error codes in a specific format?

Happy to continue working on this once the approach is confirmed 🙂

[MaximilianRau04]

Hi 👋
thanks for setting up the project locally and for fixing the CI/test issues — much appreciated.

Regarding PR #60:
If you update the PR to exclude JPA / DataSource auto-configuration instead of disabling the test, please go ahead. Once that is adjusted, you can continue with the centralized exception handling work 👍

Now to your questions:

Should IllegalArgumentException be fully replaced with custom exceptions?

Yes — in this project, that is the intended direction.

Since we explicitly want to align with the referenced repository, and that repository replaces IllegalArgumentException with domain-specific exceptions throughout, the same approach should be applied here.

Preferred structure / naming for new exceptions

Please follow the structure and naming from the reference repository as closely as possible.

That means:

• Explicit, domain-driven exception names
• No generic “catch-all” exceptions
• Grouping by domain/concern (e.g. notfound, authorization, crypto)

GlobalExceptionHandler & error code format

Yes — please mirror the error response structure from the reference repository.

Specifically:

• stable, client-facing error codes
• consistent HTTP status mapping
• uniform JSON response shape