Is it better to have an exception type for each case or a more general exception?

For me none of this would be an exception, at least for what the name implies. I consider a mechanism abuse thrown exception for normal situations that may occur in the code . I would take other mechanisms to inform that something is not valid .

But Java has the culture of abusing this mechanism. If you are going to do this you need to understand why you need the exception.

It will be used to indicate what went wrong, right? So you need to be as specific as possible, do not you?

But you have to see if you need to know whether the catch needs to be specialized or not. If you need to capture each of these issues in isolation, there's no doubt that it needs to be separated.

If you really need to catch the exception only by indicating that there was an invalidation and then with the information that is in the exception deciding what to do, then you can use only one exception. Of course, in this case the exception must have a structure capable of providing additional information for use after capture. It may even be that you have multiple invalidations in one exception, you need to anticipate this.

An example of an exception that operates this way is the SQLException " (I know, it's C #, but it's just to show the structure). It deals with the most diverse problems internally. For the application it matters that there was an SQL exception.

The biggest disadvantage of this case is that it centralizes. If you need to create new forms of exception you will have to manipulate this class. If you are to blindly follow what directs the orientation to object should separate into each class. But if you are pragmatic you have the option to centralize.

The decision is not easy and without seeing the concrete case I do not know how to help much. This case has a requirement, even if artificial, for exceptions to be separated. But the requirement is not so clear. My recommendation is to try to clarify the requirement first. If you do not think it is the best solution, try to negotiate the requirement. But you have to follow the requirement. So I see a dilemma in the question because it does not seem like this case is for you to choose what to do.

If I can choose, I think it would be a one-off exception, but the requirements are not clear for me to guarantee this.

Whether you need to create a bunch of different types of exceptions or create a single one that covers all is not as simple a decision as "see if you have a lot". This is an area where you have to look case-by-case.

What will the separation serve for? Because, if it is only to display an error in the log or something else that helps in debugging, a simple description message in RepositorioException already resolves. Creating more specialized exceptions is interesting when you need to differentiate them to take really different paths in your exception flow.

So my suggestion is that you start with a more general exception and a detail message (which you should ) fill in with specific case details so you do not get lost at the time of debugging), and when faced with the need for separate execution streams, create new exceptions that are specializations of that.

It depends. And you do not have to give up one thing to have another.

For example, in an API used by a third party, you will certainly want the possible exceptional scenarios well defined and documented, so anyone who uses it can perform the treatments as best you can.

However, on a typical system, removing something that has already been removed may simply be ignored. For example, a user, using a registration screen on a web system, repeatedly clicks the "Delete" button because the internet is slow. As a result multiple requests arrive by excluding the same object. The first will have an effect and the others will show the error that the object was not found. Because the user sees only the result of the last request, he may come to the conclusion that he has a problem with the system.

In addition, if you find it appropriate, you can have a generic exception such as ErroCadastroException that is thrown whenever an unauthorized operation is performed, such as adding a duplicate record or changing something that does not exist.

However, suppose you later see the need to include a specific validation to check if the value of a field is duplicated in order to show the user exactly what the problem is. In this case, you could specifically create an exception that extends the other and contains the error in specific. For example:

public class CpfJaExisteException extends ErroCadastroException { 
    ...
}

In this way, you can show a friendly message to the user, for example by informing that person already has a registration or even redirecting to the registration of it.

An important point here is that you can probably use this exception in the internal routines of the system, but will treat it at some point to take the necessary action.

In summary, you should only create exceptions if you want to treat them specifically at some point, otherwise use a generic exception.

Also note that there are alternatives to exceptions . For example, if there is no data in a table, return an empty list. On the screen, you can check whether or not records are returned and display some message saying there are no records returned.