Standardized Error Classification & Handling

Question

I need to standardize on how I classify and handle errors/exceptions 'gracefully'.

I currently use a process by which I report the errors to a function passing an error-number, severity-code, location-info and extra-info-string. This function returns boolean true if the error is fatal and the app should die, false otherwise. As part of it's process, apart from visual-feedback to the user, the function also log-to-file errors of above some severity-level.

Error-number indexes an array of strings explaining the type of error, e.g.:'File access','User Input','Thread-creation','Network access', etc. Severity-code is binary OR of 0,1,2 or 4, 0=informative, 1=user_retry, 2=cannot_complete, 4=cannot_continue. Location-info is module & function, and Extra-info is parameter- and local variable values.

I want to make this into a standard way of error-handling that I can put in a library and re-use in all my apps. I mainly use C/C++ on Linux, but would want to use the resultant library with other languages/platforms as well.

• An idea is to extend the error-type array to indicate some default behavior for a given severity-level, but should this then become the action taken and give no options to the user?

• Or: should such extension be a sub-array of options that the user need to pick from? The problem with this is that the options would of necessity be generalized programming-related options that may very-well completely baffle an end-user.

• Or: should each app that uses the error-lib routine pass along its own array of either errors or default behaviors - but this will defeat the purpose of the library...

• Or: should the severity-levels be handled in each app?

Or: what do you suggest? How do you handle errors? How can I improve this?

Answer 1

How you handle the errors really depends upon the application.A Web application has a different Error-Catching mechanism than A Desktop Application, and both of those differ drastically to an asynchronous messaging system.

That being said the a common practice in error handling is to handle it at the lowest possible level where it can be dealt with. This usually means the Application Layer or the GUI.

I like the severity levels. Perhaps you can have a pluggable Error-collection library with different error output providers and severity level provider.

Output providers could include things like a logginProvider and IgnoreErrorsProvider. Severity providers would probably be something implemented by each project since severity levels are usually determined by that type of project in which it occurs. (For example, network connection issues are more severe for a banking application than for a contact management system).