Technical vs Business Exceptions.
There are two main reasons why things can go wrong at runtime: technical issues that prevent the application from being used, and business logic issues that prevent the application from being misused. Many programming languages use exceptions to signal both of these situations, but they are fundamentally different and should be kept separate. Using the same exception hierarchy and class for both can cause confusion.
Technical problems can occur due to programming errors or inappropriate arguments passed to library code. It is not advisable to try to resolve these issues and instead let the exception bubble up to the highest architectural level where a general exception-handling mechanism can handle it appropriately.
On the other hand, domain-logical issues cannot be completed due to exceptional circumstances, but they are not errors. For example, if someone tries to withdraw money from an account with insufficient funds. These types of exceptions are part of the contract and should be handled separately from technical exceptions. Creating a separate exception hierarchy for these types of exceptions will provide clarity and help distinguish them from technical exceptions.
Mixing technical and business exceptions in the same hierarchy can confuse the caller about the method contract and what situations it is supposed to handle. By separating these cases, technical exceptions can be handled by the application framework, while business domain exceptions can be handled by the client code.