Click here to Skip to main content
15,891,136 members
Home / Discussions / Article Writing
   

Article Writing

 
GeneralRe: Grid computing ... Help meeeeeeee Pin
gpa200028-Jan-04 21:01
gpa200028-Jan-04 21:01 
GeneralRe: Grid computing ... Help meeeeeeee Pin
closecall29-Jan-04 17:45
closecall29-Jan-04 17:45 
GeneralRe: Grid computing ... Help meeeeeeee Pin
trungbkvn29-Jan-04 18:13
trungbkvn29-Jan-04 18:13 
GeneralRe: Grid computing ... Help meeeeeeee Pin
WillemM28-Aug-04 23:42
WillemM28-Aug-04 23:42 
QuestionFinal yr project ? Pin
raheela22-Jan-04 5:41
raheela22-Jan-04 5:41 
AnswerRe: Final yr project ? Pin
Gomac11-Feb-04 8:20
Gomac11-Feb-04 8:20 
GeneralRe: Final yr project ? Pin
Sarvesvara (BVKS) Dasa15-Feb-04 0:10
Sarvesvara (BVKS) Dasa15-Feb-04 0:10 
QuestionException Handling Strategies - Good idea? Pin
Jeff Deville20-Jan-04 18:43
Jeff Deville20-Jan-04 18:43 
All,
I've been unable to find a decent article on exception management strategies. I'd like to know what everyone thinks of this idea (this way, if the idea sucks, only a few people ridicule me. Confused | :confused: )

Basically, I'm looking for a strategy that meets the following requirements:
Goals
1. Provides an Intelligible message to the user that
a) Explains the problem
b) Provides a list of possible explanations
c) Suggests steps to remedy the issue
d) Can be told what actions are allowable in the wake of an error (continue, quit, retry)
2. Is fully configurable via XML
3. Doesn't clutter your code
4. Provides backward compatibility so if a component developed with this strategy is used by an application that does not use it, the new author does not have to handle things differently.
5. Information must be preserved as the exception is passed up the stack. (more on this later)

High level design considerations
1. My thinking is that exception handling does not need to be very fast, it is more important to be very accurate.
2. Display should be performed at the highest level (usually the display level, but not necessarily), and never anywhere lower. (Displaying an error in a utility function ties the backend code to a display technology and method, reducing it's ability to be reused. It also means that the same error may result in multiple messages to the user).

Tentative Implementation Plan
Currently I'm planning to create an exception factory, and XML files for each assembly. The user might throw an exception thusly:

try<br />
  something that breaks<br />
catch ex as exception<br />
  throw ExceptionFactory.createException(me, ex, args)<br />
end try


The factory first would check a config file to see if it should use this new exception handling mechanism, or just the built-in .net error handling. If regular handling, then it simply returns the original exception. If enhanced error handling is used, then the factory would use reflection to determine where the exception originated (the 'me' object). Then it will hit that assembly's associated XML file to find the info on this error. In this way, the code can be used for any project w/out change. It also means that the XML file could be used as an appendix of sorts. Finally, storing this info in the XML file means that it doesn't have to be in your source code. The args may be used to pass extra information. For example, if it's a file not found error, it would be helpful to know what the path is of the file that didn't exist is. All of this info is stored in a custom exception class.

When the exception is formed and thrown, it will proceed up the stack. If there is another intermediate function, the factory method is again invoked. However the factory will check to see if it is of the same type as our custom exception. If so, information can be added to the messages, and possible actions can be reduced as necessary.

This brings me to a more detailed explanation on #5. My concern is that creating an error message way down in some utility function may not make any sense at all to a user because they may not understand why that utility function was even called. (Half the time I don't even understand!) Further, a utility function is probably so technical, that no possible error message would make sense anyway. If you're performing an autosave that fails, you want to tell the user that the autosave failed, not that the filestream could not be opened... So basically, care must be taken so that information is ADDED as the exception passes up the chain to get a message like this:

-------------------------------------------------------------------------
Page copy failed <-- GUI level
because <-- added automatically
the data could not be obtained <-- next level down
because <-- added automatically
deserialization failed because <-- added by the function that threw
the file can not be found the exception in the first place

If the file: {0} exists on a network share, please check your connection to the network and try again. If the file is gone, then the data has been lost. You may either continue without this info, or quit.
<<retry>> <<continue>> <<quit>>
--------------------------------------------------------------------------

What I'm looking for is:
1. What do you think of my requirements?
2. Is this the best strategy to go with?
3. Any other general suggestions?
QuestionWould this be a good submtion? Pin
LiquidKnight14-Jan-04 10:34
LiquidKnight14-Jan-04 10:34 
AnswerRe: Would this be a good submtion? Pin
peterchen14-Jan-04 10:56
peterchen14-Jan-04 10:56 
GeneralRe: Would this be a good submtion? Pin
LiquidKnight14-Jan-04 11:50
LiquidKnight14-Jan-04 11:50 
GeneralRe: Would this be a good submtion? Pin
Colin Angus Mackay14-Jan-04 12:13
Colin Angus Mackay14-Jan-04 12:13 
GeneralRe: Would this be a good submtion? Pin
peterchen14-Jan-04 12:25
peterchen14-Jan-04 12:25 
GeneralRe: Would this be a good submtion? Pin
Anonymous14-Jan-04 12:43
Anonymous14-Jan-04 12:43 
GeneralRe: Would this be a good submtion? Pin
peterchen14-Jan-04 12:53
peterchen14-Jan-04 12:53 
GeneralRe: Would this be a good submtion? Pin
LiquidKnight14-Jan-04 13:01
LiquidKnight14-Jan-04 13:01 
GeneralRe: Would this be a good submtion? Pin
Colin Angus Mackay14-Jan-04 22:18
Colin Angus Mackay14-Jan-04 22:18 
GeneralRe: Would this be a good submtion? Pin
Nik Vogiatzis21-Jan-04 20:31
Nik Vogiatzis21-Jan-04 20:31 
GeneralRe: Would this be a good submtion? Pin
Jörgen Sigvardsson15-Jan-04 14:25
Jörgen Sigvardsson15-Jan-04 14:25 
GeneralRe: Would this be a good submtion? Pin
Nik Vogiatzis22-Jan-04 11:59
Nik Vogiatzis22-Jan-04 11:59 
GeneralNative code portabilty Pin
DataAdapter14-Jan-04 7:29
DataAdapter14-Jan-04 7:29 
GeneralRe: Native code portabilty Pin
Colin Angus Mackay14-Jan-04 12:20
Colin Angus Mackay14-Jan-04 12:20 
GeneralNeed a Tech. info sample/standart on the application product Pin
vipsy14-Jan-04 0:29
vipsy14-Jan-04 0:29 
GeneralRe: Need a Tech. info sample/standart on the application product Pin
Brad Bruce29-Jan-04 13:23
Brad Bruce29-Jan-04 13:23 
GeneralNeed Brief Articles on Peer to peer file transfer Pin
fokyy13-Jan-04 17:55
fokyy13-Jan-04 17:55 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.