Introduce custom error handling across codebase

[emrgnt-cmplxty]

Title: Introduce custom errors handling across codebase

Issue:

Right now we use boilerplate ValueError and Exception throughout the codebase. While these standard exceptions can provide basic error handling functionality, they lack the specificity and flexibility needed for effective debugging and error resolution.

Problem:

The primary issue with this approach is that it can be hard to identify exactly where an error has occurred and what caused it, especially in a large codebase. This is because standard exceptions do not provide specific context about the error, its source, or the part of the codebase it affects.

Furthermore, there may be certain scenarios in our application where we'd like to handle exceptions differently based on the type of error that occurred. This is not easily achievable with the current, generic exception handling.

Proposed Solution:

In order to provide more specific and meaningful error messages, and to handle exceptions in a more flexible way, we propose introducing custom exception classes across the codebase.

These custom exceptions should inherit from the base Exception class or appropriate subclasses (such as ValueError or TypeError), and should be designed to encapsulate a particular type of error that could occur within our application.

Here's an example of what a custom exception class might look like:

class CustomDatabaseError(Exception):
    """Raised when a specific error occurs in the database module."""
    
    def __init__(self, message="A database error occurred"):
        self.message = message
        super().__init__(self.message)

In this example, the CustomDatabaseError would be raised whenever a specific database-related error occurs, making it easier to identify and handle this specific kind of error.

Tasks:

• Review the codebase to identify areas where custom exceptions would be beneficial.
• Design custom exception classes that encapsulate specific types of errors in our application.
• Replace generic exceptions with custom exceptions throughout the codebase.
• Test the system to ensure custom exceptions are working as expected and providing more meaningful error information.
• Update documentation to reflect the introduction of custom exceptions.

Through these steps, we can create a more robust and developer-friendly error handling system that will make our codebase easier to maintain and debug.

As always, don't hesitate to ask if you have any questions or need further clarification. Your contributions to this project are highly valued!

[RKALM]

Hello everyone,

I find this issue to be quite interesting and I believe it's an area where we can really enhance the readability and maintainability of our codebase. Therefore, I am going to take this issue and start working on it.

I plan to share a pull request with the initial set of changes by tomorrow, or perhaps by Wednesday at the latest. As I'm currently in the process of familiarizing myself with the entire codebase and reading through the documentation, I estimate that this task might take me about a week to complete.

Of course, should it take longer, we can take it as an opportunity to ensure the quality of the changes is up to our high standards, and to have a rich discussion about best practices for error handling in our project.

Looking forward to working on this and hearing your thoughts!

Best regards,
Robert

[ganesh-palanikumar]

If this issue is still open, I would love to work on this. @emrgnt-cmplxty , @Exarchias

[RKALM]

Nice choice @ganesh-palanikumar! I am not working currently at this issue, so if @emrgnt-cmplxty agrees as well, feel free to jump to it!