File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Should exception classes be immutable? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Should exception classes be immutable?" Watch "Should exception classes be immutable?" New topic

Should exception classes be immutable?

Robin Sharma
Ranch Hand

Joined: Aug 24, 2005
Posts: 76

I am trying to come up with a generic exception handling framework for my project. Now, do i make the exception classes that i create as part of the framework, immutable?
If i do make them immutable, i won't be able to extend from the base exception classes. But, making these classes immutable is also compelling because you normally do not modify an exception class once it's created.

What are the pros and cons of both?


There is always a bug :-)
Campbell Ritchie

Joined: Oct 13, 2005
Posts: 46427
Why are you producing new Exceptions in the first place? I think it is a bad idea to go round producing new classes when there are Exceptions already available.
There are a few which might be worth creating, like the OverflowException described in Thinking in Java (B Eckels), but otherwise you are probably better using existing classes.

Renato Losio
Ranch Hand

Joined: Nov 23, 2005
Posts: 99

I can't see any advantage in doing that. I mean, all the goal of an immutable object (thread safe, no changes, lock, ...) don't usually apply to a state where an exception is thrown. Morover, I can't see many reasons why I may need to subclass an exception in the future. So I wouldn't declare it final.


Renato Losio - -
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Originally posted by Campbell Ritchie:
Why are you producing new Exceptions in the first place? I think it is a bad idea to go round producing new classes when there are Exceptions already available.

I'm pretty sure I don't agree with that at all.

The existing built-in Java exceptions have specific documented meanings. It is quite rare to come across a situation where your code needs to throw an exception that means exactly the same as a built-in exception. You should not throw a built-in exception in a situation other than the one for which it is intended, as that is really confusing.

You can throw basic java.lang.Exception or java.lang.RuntimeException. However, doing so does not give calling code an opportunity to catch that specific exception, while allowing others to pass through. So, I don't think that's a good idea either.

I believe you can and should create your own exceptions, to describe the specific problems that your code has encountered.

I think it is sometimes appropriate to subclass existing exceptions (built-in or your own), but not all that often. Example: you might define a FooResourceNotFoundException, for any resource not found in your library Foo. But you might find it useful to have a WibbleNotFoundException, subclassing FooResourceNotFoundException, for when the specific resource Wibble was not found, within library Foo.

I think that data fields of exception classes generally should be final, because there's generally no good reason to go around changing them, after throwing the exception.

Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Here is a past discussion you may find useful.

"I'm not back." - Bill Harding, Twister
I agree. Here's the link:
subject: Should exception classes be immutable?
It's not a secret anymore!