Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Should exception classes be immutable?

 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

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?

Thanks.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50258
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

CR
 
Renato Losio
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.

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
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is a past discussion you may find useful.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic