What to write in an Exception Class (Exception)?

Question

I was looking at that question at Stackoverflow ^en How can I write custom Exceptions? and the most well-voted (and accepted) response was:

public class MyNewException extends RuntimeException {

    public MyNewException(){
        super();
    }

    public MyNewException(String message){
        super(message);
    }
}

That is, he just declared a class and called the builders of the parent class.

What is the purpose of this? By my (little) understanding of the creation of new "exceptions" are basically to identify them, I’m sure?

I’ve seen code like this in PHP:

try{
   // Algum Código
} catch(UmaException $e) {
   // Faz alguma coisa
} catch(OutraException $e) {
   // Faz outra coisa
}

Then the creation of the various exceptions are to identify them and prepare an output according to the type of exception? The message passed as parameter would no longer do this job?

Answer 1

Most of the time you will create exceptions just like that. At first it seems weird, but think about the semantics you want to pass.

It’s no different than you saying there was a Exception and a BadFileFormat? Even if internally these classes change nothing, the second is much more specific and informative. And as it is more specific it can be caught with greater granularity.

Of course it is likely that the text message that the exception usually has will also be customized. Often even if you pass some text when you launch the exception, the actual text is formed by this parameter and something else that already exists within the class.

You have to think about how much you want to have this granularity. It’s good to some extent. There are cases where it is better to put this detail within the exception itself. See database error exceptions, there is no exception for every possible error. The detail is within the class, possibly with properties that only this exception has. So there are cases where there are a lot more things written in the exception.

Eventually you can write a method that helps you recover from the exception, but I don’t see anyone doing it and I think it’s bad practice. My intuition says yes, but I have no basis to say.

But the most common is to add specific properties with relevant information. For example, an SQL error may have a ErrorCode and ErrorMessage (this is more specific than the general exception message. Think about the information that you can add (that is available) and that the code that captures the exception can use in some useful way, whether to decide what to do, or to present more user-oriented information or put in the log.

I often say that exception is not always the best mechanism, although the languages and frameworks and you end up having to adapt to it.

Has a my answer that shows when to create and throw exceptions, probably helps to understand this question.

Other relevant information before leaving making exception for everything.

Answer 2

Correct, so if at some point in your system, that is, in some part of your code you need to raise an exception, then it would raise an exception already known to you.

Say you want to validate if the user is logged in to your system, and if they are not, you would make an exception. then you would do the following:

public class UsuarioNaoLogado extends RuntimeException {

    public UsuarioNaoLogado (){
        super();
    }

    public UsuarioNaoLogado (String message){
        super(message);
    }
}

And to raise an exception that the user is not logged in would do so:

 throw new UsuarioNaoLogado();

This way at several points of your source code you can raise an exception signaling that the user is not logged in using the same Exception in the case UsuarioNaoLogado().

But you can also create a Execption to save more information for example when determined Execption you would save in a database the date the error occurred, then do inside the class for example.