This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
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. Regards,
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
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.
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. Regards Karthicraja
Joined: Jan 15, 2002
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.
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. PCS
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!