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.
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.
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.
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.