Java: Throwing exceptions

Question

Is it a good idea to pass an object to a constructor when throwing an exception?

Let's imagine that there is next code somewhere in service package.

throw new MyException(object);

MyException class:

Object object;
public MyException(Object object) {
    super();
    this.object = object;
}

public Object getObject() {
    return object;
}

And later, let's say, in GUI we have to handle the exception thrown in service. We just catch an exception and want to access object passed in the constructor. This works. But is it a correct from the point of style?

Is the use of getObject() a correct approach?

Answer 1

I would say it depends on what you are doing with getObject . If you are just using it to report the error or manage the recovery from the exception then there's nothing wrong with this. I would pass something more specific than an object. For example, I might give the exception information about the cause of the error and capture any useful information that might help solve the error.

If, on the other hand, you are using this object to continue some normal branch of control flow, then that wouldn't be considered a normal use of exceptions! To repeat the obvious, exceptions are for exceptional situations and nothing more. If you're doing something else with them it's generally bad idea.

If you are using an exception to capture results that you are processing later then that's a bad design smell. Look at refactoring your code to write those objects out to a store for processing later, or some such. Don't abuse exceptions.

Answer 2

In general, yes, it's good to add data to exception objects which might be useful to the code handling the exception.

However, a getObject() method that returns an Object is way too generic - the name of the method and preferably also the type of the object should be specific to the exception - create multiple exception classes if necessary, then you can distinguish them in catch blocks.

Finally, this kind of thing could be abused for regular control flow. I do not agree with the standard dogma that this is inherently "evil" - exceptions are a control flow mechanism. But they're one that's bad for maintainability because it connects pieces of code implicitly. So it should only be used if you really need a way to pass control flow several levels up the call stack and have thought hard about alternatives.

Answer 3

As always, it will depend on your system strtucture and on what you want to achieve, but IMO this is an acceptable way to go.

Indeed, this is the way the default exception API handles the error messages and causes, passing them as constructor parameters (see Exception constructors API Doc) to be handled later.

Answer 4

The class that catches the exception depends on the (static) class of the object that is encapsulated in the exception. It's usually a good idea to minimize dependencies. That's why I would not encapsulate classes, that are internal to a component, into exceptions. I would encapsulate public classes of a component in an exception only if the exception and the encapsulated class belong to the same component.