What to write in an Exception Class?

4

I was looking at this question in StackOverflow in How can I write custom Exceptions? and the most voted (and accepted) response was:

public class MyNewException extends RuntimeException {

    public MyNewException(){
        super();
    }

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

That is, it just declared a class and called the constructors of the parent class.

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

I've seen code similar to this in PHP:

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

So the creation of the various exceptions is to identify them and prepare an output according to the type of exception? The message passed as a parameter would not do this job anymore?

    
asked by anonymous 24.09.2015 / 21:55

2 answers

5

Most of the time you will create exceptions anyway. At first it seems weird, but think about the semantics you want to go through.

Is not it quite different to say that there was a Exception and a BadFileFormat ? Even though internally these classes do not change anything, the second is much more specific and informative. And being more specific can be captured with greater granularity .

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

You have to think how much you want to have this granularity. She is good up to a point. There are cases where it is best to place this detail within the exception itself. See the database error exceptions . There is no exception for every possible error. The breakdown is within the class, possibly with properties that only this exception has. So there are cases that there are a lot more things that are written in the exception.

Eventually you can write a method that helps you recover from the exception, but I do not see anyone doing this and I think it's a bad practice. My intuition says yes, but I have no basis to affirm.

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

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

You have a answer of mine that shows when to create and throw exceptions , / p>

Another relevant information before exiting by making exceptions for everything .

    
24.09.2015 / 22:06
1

Correct, so if at some point in your system, that is, somewhere in your code you need to raise an exception, then you would raise an exception that you already know.

Let's say you want to validate if the user is logged in to your system, and if he is not, you would raise 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();

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

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

    
24.09.2015 / 22:01