Create more specific or more generic custom exceptions?

Question

Taking into account that in a project is used the practice of creating custom exceptions, which makes more sense?

I mean, make an exception for every possible error predicted in the code by specifying the name of the exception class with the exact error, or else try to generalize into "groups" of errors?

Well specified custom class example:

   public class DataDeNascimentoDoUsuarioInvalidaException extends Exception {

   }

Example of a less specific exception class:

   public class CadastroDeUsuarioException extends Exception {

   }

Example of a more widespread custom exception class:

   public class CadastroException extends Exception{

   }

Is there any criterion for this question (for example some author, or term)?

I am aware that if I create very specific exceptions, a large project will have a huge amount of classes, but I know that there are developers who use this practice, which in my layman’s view is bad practice.

I read the post very similar to the one that talks about specific error treatment x generalized (post), but this post does not address custom exceptions.

Answer 1

There’s no definitive answer to that. I know people always want a universal magic rule, but only the problem, the context, the environment being developed can determine what is most appropriate.

Hierarchy

This does not mean that every exception should be derived from Exception, Maybe the biggest mistake is in there. You can create a hierarchy of types, between having a template of very specific exceptions and a model of having grouped exceptions, stick to both, can have levels.

To model well you need to understand taxonomy and ontology (some speak dialectics too), even without formal study, is the secret.

It is not bad practice to create a lot of exception if it is the chosen model. There is always the model where the exception is not used for validation, for flow control. I have spoken several times about this, but many people prefer the exception for everything. If one chooses it has to pay the price, and then the correct thing is to create a lot of classes. One of the reasons for not adopting an exception is precisely not having to create many classes, although it is not the biggest reason.

If you’re gonna use exception, use right, and be specific. The criticism you make of other models is that you can’t specify the error, which is not true in most cases, so if you choose the exception and don’t use your theoretical advantage, why are you doing it? This is important because most programmers use the exception in the wrong way and gain the worst of both worlds. And to me it’s a clear demonstration that she doesn’t even want to use the exception, but she uses it because she’s learned it, she does what everybody else is doing without questioning why.

In a very well modeled domain, in which exceptions are the means of communication of data invalidity it is necessary a lot of same classes. So some people prefer a more pragmatic modeling rather than making everything perfect. I talked about it in Why certain domains are easier to model than others?.

Importance of creating specific classes

The post quoted does not address explicitly customised exceptions, but implicitly is worth all that is there. In fact there are many questions about exception on the site but few of how to create custom exceptions, you know why? Because almost nobody creates them. It’s hard work and people don’t want work. So you should use the workless mechanism and avoid one that gives and make wrong use of it to save.

One of the reasons people capture wrong (generic) exceptions is that they don’t know or don’t want to create custom exceptions, and that’s a mistake. One mistake contaminates the other.

Domain

If you’re going to do it anyway, it doesn’t really matter. If you want to do it right, you have to ask the domain what it needs. Almost always he needs an exception just for himself.

It’s all about the level of abstraction you’re dealing with. That’s one of the hardest things to define. That’s why I always say that most developers model wrong, including me, because it is very difficult and some paradigms are more difficult because it forces you to model right from the beginning (OOP, cof cof, to fix the error changes so much that it becomes another object).

It depends on how specific you have to be in the treatment of that. Does it make sense to make an exception if you’re not going to capture it generically? For most people you didn’t need to have different exceptions, you just had to have the Exception, they don’t care about the rest. It’s a complete mistake, but for their practice it’s the right thing to do.

For a real engineer, you say that Exception should be an abstract class, which does not solve the problem of wrong capture, but solves the person being too generic when it throws an exception. And since the majority did not have the concern that the AP had, will complain and say that the language was wrong not to let instantiate this class.

In business domains if you opt for the exception it is almost certain that each class will have its own exception together, or some. Unless the classes have strong relationships.

Compromise

Another important detail is that some exceptions may contain more specific code instead of creating hierarchy. I have already mentioned this in It is better to have a type of exception for each case or a more general exception? and Treat Exception by code and real example in How to handle duplicate key error?

I give an idea about choosing this in Best practices with Java exception handling.

I think it should be mandatory reading, even if I disagree: Why should we avoid returning error codes?.

Either use another mechanism or use the exception in the right way. Exception was created to be specific, not to be is misrepresentation of the mechanism. How much is right is where enters the "art" used in engineering.

Turn and move I see some atrocities around. It works, but it is not the right one, one hour you pay a price. Careful not to abuse this.

Often the problem is up to another, but I will not go into this field because it involves the whole way we make software "modern".

Completion

But if you don’t understand everything, you can make the wrong decision.

Read all you can about exception and a little more. And then start making your decisions. Only qualified experience (quantified does not help much, doing wrong for 20 years only hinders) will make you make better decisions in each case.

Some people prefer to simplify and choose a way and do so in everything. Spend less time deciding, and she’ll deal with the consequences of that decision.

Your choice will be your opinion, but the basis of knowledge can be obtained objectively or at least with a reasoned subjectivity, until you will have a solid opinion.

One more answer that can help.

An answer I gave that gives a good idea about it but that some do not like, even she agree with one of the guys who understands computing the most and has extraordinary results to show. I didn’t create that concept, I reproduced.

And yet: It is good practice to make an exception in such cases?.

It is collateral but worth to help decide (in every language is like this, C++ has tried to create a better mechanism): Exceptions consume a lot of processing. Truth or legend?. Imagine reading external data and validating one by one. What would take seconds can take hours, seriously, then one doesn’t understand why the system is slow.

Search on the site that has other interesting. And some people think differently.