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

Design Issue

 
raphael Bereh
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,
 
Sayed Ibrahim Hashimi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Problem : I have too many classes inheriting from the abstract exception class.

How many are we talking about?
 
raphael Bereh
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Thanks
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Ron Ditch
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
raphael Bereh
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 189
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic