Is it better to have a kind of exception for each case or a more general exception?

Asked

Viewed 189 times

7

A project from my college was asked to create a class called RepositorioException which is a subclass of Exception to be used for handling exceptions in repository classes, where: RepositorioMotorista, RepositorioViagem, RepositorioSolicitante.

Next: Develop an exception model using the class RepositorioException for the repositories, the examples below would be some that were asked to be implemented.

Examples:

  • Additionraised exception
  • Removernaoexisteexception
  • Removervazioexception
  • Removervazioexception
  • Alterarnaoexisteexception
  • Alterarvazioexception

My question would be about these cases of Exception if I can create them in the class itself RepositorioException or whether each would have been created separately by inheriting Exception.

java exception software-engineering
  • 1

    I believe that first you must assess whether there is even a need to create so many exceptions. I find it very unnecessary to go out creating a lot of exceptions for each occurrence in the system.

  • @Pabloalmeida seems that his title changed the meaning of the question a little.

  • @diegofm It is that the previous title implied that it was going to be a question about how to create new types of exception. Upon entering, I came across a question about best practices. I don’t know if the new title was perfect, but I think you have to go that way, at least.

  • @Pabloalmeida is right, the question is not very clear either, but tends to fall more to this same side.

  • @diegofm Your guess was better than mine. : ) .

  • my doubt is whether a Repositorioexception class that is subclass of Exception, could control all exceptions that Repositorio could give Throw, and how it would be done if possible with example code.

  • @Latreta Edit the question and provide more details then, the question ended up generating unnecessary doubts because it is not clear.

  • @Latreta These exceptions that you mentioned already exist? Who is releasing Repositorioexception ?

  • @Pabloalmeida I have to create them to treat each case, I put the link of the project instructions, maybe you can understand better, I never messed with exceptions I feel lost.

  • @Latreta His problem is more in the question of the interpretation of the problem. Reading the file you gave me, it seems clear that you only have to release Repositorioexception and pass a detailed message for each case, as I suggested in the reply. But it’s okay... since you never messed with it, it’s normal to have doubts. I will take the liberty of editing your question to make it similar to my initial edition to still be useful for future visitors. The answer to your exercise is this: just create Repositorioexception and launch it with different messages.

Show 5 more comments

3 answers

6


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

But Java has a culture of abusing this mechanism. If you’re really going to do this you need to understand why you need the exception.

It will be used to indicate what went wrong, right? So it needs to be as specific as possible, not true?

But you have to see if you need to know if the catch needs to be specialized or not. If you need to capture each of these problems in isolation, there is no doubt that you need separation.

If you actually need to capture the exception only indicating that there was an invalidity and then with the information that is in the exception decide what to do, then you can use only one exception. Of course in this case the exception needs to have a structure capable of providing additional information for use after capture. It may even be that you have several invalidities in one exception, you need to predict this.

An example of an exception that operated in this way is the SQLException (I know, it’s C#, but it’s just to show the structure). It treats the most diverse problems internally. For the application it is important 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 blindly following what the orientation dictates, the object should separate in each class. But if you are pragmatic, and you are correct, you have the option centering.

The decision is not easy and without seeing the concrete case I do not know how much help. This case to have a requirement, even if artificial, for the exceptions to be separated, but this requirement is not so clear. My recommendation is to try to clarify the requirement first of all. 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 doesn’t seem that this case is for you to choose what to do.

If I may choose I think I would go from single exception but the requirements are not clear for me to ensure this.

  • In this context, it gets out of hand, because as a chair project I’m kind of obliged to follow the "specifications" given by the teacher. I understood the reference on Sqlexception used a little when working with Sqlite.

  • very well put as always. The exception generates a stack of information from where the code generated such a situation being an orthogonal requirement to the purpose of the system.

  • I think the biggest disadvantage of putting type information into an internal structure is not that it centralizes. Centralizing, by itself, is not a problem. What I see as a problem there is that you are simulating a type system, but without taking advantage of the structures that were made for it (the class-based type system). That is, your code does not express as well as it could what your intention is.

  • @Latreta, your teacher does not accept to justify with good practices and techniques of software engineering? I know that in some clergy it is dangerous to demonstrate that the teacher is mistaken, but he can value his commitment to seek the most appropriate way to use such resources.

  • @Pabloalmeida centering is a huge problem in some systems. Probably not in this one. It’s not usually in mine. I go by pragmatism. The same way having everything on one guy doesn’t usually cause problems in cases like this. Note that I am not saying that I should abuse this, even if I should not create new exceptions, I am opposed to this and I think that one of the biggest mistakes that programmers make is just using the exceptions ready, or just the Exception. as is common. I know there are people who think differently, but after you use exception where you should not, for me anything is worth...

  • ...since anything you do will be bad enough. I don’t know the problem in detail, so I can’t judge, but in cases where and the exception is used to indicate invalidity, you rarely need to have one for each invalidity, because who will treat that is a mechanism that deals with validations, Catch him and deliver him to see what he has to do. To tell you the truth, I don’t even know how to argue with something that’s already wrong with the foundation. @Latreta if specified, I do what I’m told and don’t worry.

  • @The problem I’m talking about has more to do with readability. Of course, when the going gets tough, some sacrifice has to be made, so you’re right to be pragmatic. I just really wanted to point out what is the problem of putting type information inside, from a point of view that doesn’t come from object orientation, because the way you said it, it seemed there was no objective advantage beyond (dis)centralization.

  • 1

    @Pabloalmeida there are other yes, and the correct type is one of them, not only by capture, but also by semantics, including the structure. It is true that most exceptions only have a "useful personalized" information message, but do not need and in many cases should not be so.

  • I have already decided, I will use Repositorioexception to treat all Repositorio cases by just changing the message to each one instead of creating several classes and the other classes of Exception that were in fact explicitly asked to be created, I will create.

Show 4 more comments

3

The decision whether it is necessary to create a lot of different types of exception or create one that covers all is not as simple a decision as "see if it has a lot". This is an area where you have to look case by case.

What good is separation? Because if it’s just to display a log error or something else that helps debug, a simple description message on RepositorioException already resolves. Creating more specialized exceptions is interesting when you need to differentiate them to take really different paths in your exception flow.

Therefore, my suggestion is that you start with a more general exception and a message of details (that you must fill in with case-specific details, so as not to get lost at debugging time) and, when faced with the need for separate execution flows, go creating new exceptions that are specializations of this.

1

It depends. And you don’t have to give up one thing to have another.

For example, in an API used by third parties, you will certainly want the possible well-defined and documented exceptional scenarios, so whoever uses it can perform the treatments as best suits.

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

Also, if you think it’s appropriate, you may have a generic exception like ErroCadastroException that is launched whenever an unauthorized operation is executed, such as adding a duplicate record or changing something that does not exist.

However, suppose you then see the need to include a specific validation to verify that 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 to another and contains the specific error. For example:

public class CpfJaExisteException extends ErroCadastroException { 
    ...
}

This way, you can show a friendly message to the user, for example stating that that person already has registration or even redirecting to its registration.

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

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

Note also that there is 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 there are any records returned and display some message saying there are no records returned.

Browser other questions tagged java exception software-engineering

You are not signed in. Login or sign up in order to post.