New exception class the extends exception class and has two constructors

Question

Create a new exception class IllegalDimensionException that extends Exception class. It will have two constructors, one default- value and one explicit value that uses the message "Illegal dimension for the figure you specified.

Does this seem to be correct way of doing this??

public class IllegalDimensionException extends Exception {
    String message; //the message that will be used
    String Eplicitm = "Illegal dimension for the figure you specified";

    //constructor one
    public IllegalDimensionException (String m){
        m = message;
    }
     //constructor two
    public IllegalDimensionException(String E){
        E = Eplicitm;

    }
    public static void main(String[] args){
        return E;
    }

}

Im having trouble creating two constructors without one being void? Any suggestions in how I can get this to correctly work??

Answer 1

Constructor should not have return type, so your second "Constructor" is not actually constructor, instead it is a method with constructor like name. I am wondering why it is not giving you any error since you do not return anything from here. And if you just remove void from the second one, it will not work because both of the constructors then will have same type of arguements, so will not be overlaoded consturctor, instead would be duplicates. In which case you will get error again. Please look at this link for the real answer of your question, How to define custom exception class in Java, the easiest way?

Answer 2

Any two constructors (or any methods for that matter) must have a different method fingerprint (aka signature). The fingerprint consists of;

• The method name
• The method return type
• The method parameters (by type)

You are trying to create two constructors that have the same fingerprint, which is not allowed. After all, how does the compiler know which method you are trying to call?

As a side note; your code makes little sense:

public IllegalDimensionException (String m){
    m = message;
}

Has literally no effect, you are overwriting the value of your local variable m with your instance variable message...I can only assume you were meaning to do this the other way around?

Answer 3

Maybe something like that answer your question:

public IllegalDimensionException (String m) {
    super(m); // you may use the exception message member instead of defining yours
    message = m; 
}

public IllegalDimensionException(){
    this(Eplicitm);
}

Thus you really have two constructors: one with default value and one with custom message. If this is what you expect, the Eplicitm should be a constant (static final).

Answer 4

This might be what you are looking for. The question you are answering is unclear, so I'm not sure:

public final class IllegalDimensionException extends Exception {
  private static final String DEFAULT = 
      "Illegal dimension for the figure you specified";

  //constructor one
  public IllegalDimensionException(){
    super(DEFAULT);
  }

  //constructor two
  public IllegalDimensionException(String message){
    super(message);
  }
}

Note the usage of super() to pass the exception message correctly to the super class.

Answer 5

It will have two constructors, one default- value and one explicit value that uses the message "Illegal dimension for the figure you specified.

It sounds like what you really need for your two constructors are a default (parameter-less) one as well as one which accepts a String parameter. e.g.,

public IllegalDimensionException() {
    super(Eplicitm);
}

public IllegalDimensionException(String m) {
    message = m;
}

The super() call in the default constructor will call Exception's constructor, which accepts a String, and pass up your Eplicitm to it.

However you are making several fundamental flaws in the logic of your code snippet above which I'd like to point out to you:

1. You can not specify an extra return type for a constructor (as you do in your "constructor two" with public void IllegalDimensionException). This is because IllegalDimensionException essentially is the return type, as you are creating a new instance of the object with it. Your above signature will instead create a new method called IllegalDimensionException which returns void and must be called by an instance of this exception... so you've essentially created a setter method with an overly complex (and poorly formatted) name.

2. It does not make sense for an Exception to have a main(String[]) method. A main() is essentially the kick start for an entire program, while an Exception is something that is created when something goes wrong within a program. As you create more complex projects, you will want to keep the function of each class fundamentally separate, distinct, and logical.

3. A constant such as a default value should be declared as private static final. As your code stands, any code that can obtain an instance of your IllegalDimensionException can change the default message by simply calling theException.Eplicitm = "Yo yo yo, wassup.". Not a very helpful error message. This is because the default privacy of variables is public. Fortunately, you have not declared it static yet, so such a change would only affect one instance of the exception... but it is much better practice for there to be only one immutable version of this across all possible exceptions that are created.

4. Variable names should be in camel case (variableName) while class names should begin with all capitals (MyClass). Constants should be in all upper-case with separations as underscores (MY_CONSTANT_VALUE).

Some of the above might sound nit picky, but it's really not. All of the above either close loopholes in your code (some of which are pretty dangerous) or make your code substantially more readable (which you'll find is a great boon - because even you will forget why in the heck you wrote some section of code when you go back to look at it three months later). For example, I'm sure I'm not the only professional programmer who took a while to figure out what you meant by Eplicitm (apart from the spelling), because it looks like the name of a complex, custom-defined object... not a String!