0

Whenever I need to define a custom exception, if it's message will not change depending on context, I put the message inside that exception. Like this:

public class UserNotFoundException extends RuntimeException {

    public UserNotFoundException() {
        super("User with given name is not found!");
    }
}

Instead of this:

public class UserNotFoundException extends RuntimeException {

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

So I don't need to provide a message each time I throw this exception, I know that the message should be same in every place.

Do you think there is a problem in my approach? Which one would you prefer, and why?

Utku Özdemir
  • 7,390
  • 2
  • 52
  • 49
  • 1
    if the message is fixed, then the first approach is legit. Though i would use a `private final static String message` to keep the string. – Olayinka Aug 09 '14 at 22:05
  • Essentially this is "should I hardcode my exception message into the constructor". No. Someone else may come along at some point in the future and decide that they want a different message. *However*, you're going to find that there are a number differing opinions on this, which puts this question dangerously close to "Primarily opinion based". – JonK Aug 09 '14 at 22:06

2 Answers2

5

Why not allow the message to be supplied, but provide a default.

public class UserNotFoundException extends RuntimeException {

    private static final String DEFAULT_MESSAGE = "User with given name is not found!";

    public UserNotFoundException() {
        this(DEFAULT_MESSAGE);
    }

    public UserNotFoundException(String message) {
        super(message);
    }
}
Don Roby
  • 40,677
  • 6
  • 91
  • 113
  • This makes sense. So do you think there is nothing wrong with exceptions containing their own messages? Because I don't see it much in libraries, frameworks etc. – Utku Özdemir Aug 09 '14 at 22:43
  • Umm… throws an error. It should be `private static final String DEFAULT_MESSAGE` – Quintec Aug 09 '14 at 23:35
  • 1
    I think there is nothing wrong with exceptions supplying their own message, but that you're better off providing a way for other developers to use it differently. But that's just my opinion... – Don Roby Aug 10 '14 at 00:26
  • Which method invoked by super() ? – partho Mar 05 '16 at 06:55
1

I think it will only make sense for you to use

public class UserNotFoundException extends RuntimeException {

    public UserNotFoundException() {
        super("User with given name is not found!");
    }
}

If and only if you uses throws this Exception when a user with a given name is not found. But this is not the right approach. Take for example, if Java source have written such hard coded code. You wouldn't be able to even define your own custom message. The Best Practices will be the second approach

public class UserNotFoundException extends RuntimeException {

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

so that you or anyother programmer that might like to extend your code can conveniently reuse your custom exception. REMEMBER re-usability is one of the core features of OOP. Any practice that is contrarily to that is not a very good practice.

Paullo
  • 2,038
  • 4
  • 25
  • 50
  • Which method invoked by super() ? – partho Mar 05 '16 at 06:55
  • 1
    super(...) is literally a java keyword which invokes the parent/inherited class. All Java classes implicitly inherits from the Object Class where there is no explicit use of the extends keyword. To answer your question: super(message) in this case will invoke RuntimeException(message) – Paullo Mar 05 '16 at 18:37