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 Design Issue 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 "Design Issue" Watch "Design Issue" New topic

Design Issue

raphael Bereh
Ranch Hand

Joined: Jan 15, 2002
Posts: 79
Hi All,
I will need your point of View On the Following :
I am implementing a range of exceptions for an Application. Each exception has :
- an ID (integer describing the type of error),
- a Source (the device that threw the exception),
- an array of data describing the precise fault,
The ID allows the definition of the following :
- The summary of the message (concise description),
- The Category of the Exception (if it is a : ERROR, INFORMATION, WARNING, etc.)
Finally, the ID and the array of data determine the precise description of the fault.
In a first approach , I want to use an Abstract Factory and make each Type of error a class.
Problem : I have too many classes inheriting from the abstract exception class.
Advantage : Parsing the array of data to determine the exact description of the fault is easier in each class.
In a second approach, I use One Exception Class where ID is a field.
Advantage : With the right Collection Interface or Class, ID is Mapped to Category,Summary.
Problem : ID and Data determine most of the description, sometimes, and additional parameter is needed, waht amkes it very difficult to implement without using a HUGE Switch Statement !
Please comment and suggest you approach to the issue.

Sayed Ibrahim Hashimi
Ranch Hand

Joined: May 17, 2001
Posts: 148
Problem : I have too many classes inheriting from the abstract exception class.

How many are we talking about?

SCJP 1.4<br /><a href="" target="_blank" rel="nofollow"></a>
raphael Bereh
Ranch Hand

Joined: Jan 15, 2002
Posts: 79
25 at the moment and if any new exception has do be added in the future it will have to inherit from the abstract class.
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
What about a combined approach? Only use subclassing when behaviour differs strongly enough.
For example, in the switch statement you mentioned, I guess there would be some very similar blocks, and some more different. By factoring out the differences in different subclasses, you could possibly get totally rid of the switch.
Hard to give more concrete advice without having some actual code at hand, though...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ron Ditch
Ranch Hand

Joined: May 16, 2002
Posts: 33
Why not just create an exception class that takes as argument to its constructor what you think is relevant to log.
Then inside your constructor, pass the instantiation arguments to whatever logging api you are using.
Karthicraja Gopalakrishnan

Joined: Oct 22, 2002
Posts: 1
Hi All,
I think having one exception class and many error class for various errors will be a good idea. Let your error class hold a genuine static error information, using this information the exception class can build problem status dynamically. May be a decorator class to format the error message will solve the problem of Switch statements.
Since the problem context is not very clear too me, i have written a solution that came to my mind.
raphael Bereh
Ranch Hand

Joined: Jan 15, 2002
Posts: 79
Hi All,
Thanks for your suggestions.
With the help of "Effective Java" from Joshua Bloch, I have design an Abstract class that encapsulates most of the behavior for an error, so only a few methods were left for each specific error to implement as needed. I still had to extend my abstract class 30 times, but the deesign sounds more appropriate to me ! I will though take any optimal design proposition seriously.
Thanks again.
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
I have nothing substantive to add, but little alarm bells started going off as I read the description of your application design.
Are you doing program flow via exception handling? If so, then you may want to take a higher level view of your design.
If you are simply interested in incorporating detailed/rich exception behavior to your API, you may want to read through this discussion.

Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
I agree. Here's the link:
subject: Design Issue
It's not a secret anymore!