Java - how to overwrite getMessage() for custom checked and unchecked exceptions using one implementation?

Question

How to have MyException and MyRuntimeException use the same custom getMessage() implementation?

As Java does not come with multiple inheritance I don't know what to do. At the moment I have duplicate code in both classes...

Important detail: getMessage() does stuff like this.class.getName(). So I do need getMessage() to use reflections cause i need the classname of the object for localization.

So either I need a solution for my first question or a solution on how to use reflections within static methods cause then I could use some utility class which both exceptions could use?

One solution might be a static method in some helper class and then using this:

return new Object() { }.getClass().getEnclosingClass().getEnclosingClass();

Isn't it?

You need to post some code. How do `MyException` and `MyRuntimeException` use `getMessage()`? What is it a custom implementation of? — Miserable Variable, Jan 04 '13 at 21:02

Krease · Accepted Answer · 2013-01-04T21:28:14.713

7

Try making a static shared helper function to implement your custom getMessage:

class MyException extends Exception {
    ....
    public String getMessage() {
        return ExceptionHelper.getMessage(this);
    }
}

class MyRuntimeException extends RuntimeException {
    ....
    public String getMessage() {
        return ExceptionHelper.getMessage(this);
    }
}

class ExceptionHelper {
    public static String getMessage(Exception e) {
        // your shared impl here
    }
}

Edit - if your Exception subclasses have more than just an impl of getMessage copy-pasted between them, you may want to share that as well. A slight tweak of the above to turn the static helper into an encapsulated class will handle this well.

For example: create a class named something like ExceptionDetails, where this shared code and variables (and any other duplication) could live, and each Exception subclass would have their own instance of ExceptionDetails.

edited Jan 04 '13 at 21:28

answered Jan 04 '13 at 21:08

Krease

15,805
8
54
86

You beat me by a few seconds. +1. – JB Nizet Jan 04 '13 at 21:11
If it turns out that there's more complexity to the message, an instance would be preferable...but yeah, a static helper is good. – Ladlestein Jan 04 '13 at 21:15
That's part of why I'm passing in the Exception to the helper, so you can get any information you want from the exception when building the message. – Krease Jan 04 '13 at 21:18
It seemed to me that `getMessage()` uses fields that also need to be duplicated in the two exception classes, in which case this will not work. – Miserable Variable Jan 04 '13 at 21:18
thnx for this easy solution :) – Gerrit Jan 04 '13 at 21:24
@MiserableVariable - I've updated my answer to account for the case where there is more duplication (such as variables or other functions) – Krease Jan 04 '13 at 21:29
Yes, the old nested classes as fake multiple inheritance, actually only two super classes :) – Miserable Variable Jan 04 '13 at 21:47

Ladlestein · Answer 2 · 2013-01-04T23:19:09.337

You have to put the real implementation of getMessage() into a new concrete class, and delegate to an instance of that class in MyException and MyRuntimeException.

class MyExceptionMessage {
  public String getMessage() { ... }
}

class MyException extends Exception {
  private MyExceptionMessage messager;

  public String getMessage() { return messager.getMessage; }
}

class MyRuntimeException extends RuntimeException {
  private MyExceptionMessage messager;

  public String getMessage() { return messager.getMessage; }
}

You can create an instance of MyExceptionMessage in the constructor of each exception class, or some other way. As you've noted, you're stuck with single inheritance, so there's no way to avoid delegation if you want to reuse the implementation between the two classes.

As Chris has noted, in his answer, a static helper method makes sense, too. At least until your message strategy is complex enough to warrant some instances that you can compose with.

EDIT:

To access the name of the exception class, pass something into to the MyExceptionMessage constructor - you could pass in the exception object, or its class, or the name of the class. You could also define an interface that your exceptions implement, containing a method that tells the messager whatever it needs to know:

interface Messagable {
  public String getMessageFragment();
}

class MyExceptionMessage {
  public String getMessage(Messageable) { 
    return "something" + messagable.getMessageFragment() + "something else";
  }
}

class MyException extends Exception implements Messagable {
  private MyExceptionMessage messager;
  public String getMessage() { 
    return messager.getMessage(this);
  }
}

// class MyRuntimeException would have a similar getMessage() implementation

Chris's solution does not work if there are additional fields duplicated in the two exception classes. With this approach, those fields can also be moved to the contained class, but should be named something else — Miserable Variable, Jan 04 '13 at 21:25
Using your solution to get the correct classname (the name of the exception that has been thrown and not the utility class) within getMessage() i must use the enclosing class name trick i also mentioned or do i miss something? — Gerrit, Jan 04 '13 at 21:31
Oops, I didn't pay attention to that part, @xstring. I've updated my answer. — Ladlestein, Jan 04 '13 at 23:19

Java - how to overwrite getMessage() for custom checked and unchecked exceptions using one implementation?

2 Answers2