Standardized Error Classification and Handling

Question

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

I am currently using a process by which I report errors to a function that passes the error number, severity code, location information, and additional information. This function returns a boolean true if the error is fatal and the application must die, otherwise false. As part of this process, in addition to visual feedback from the user, the function also makes journal errors with several levels of severity.

The number of errors is indexed by an array of lines explaining the type of error, for example: “Access to files”, “User input”, “Creating a theme”, “Network access”, etc. The severity code is binary OR 0, 1,2, or 4, 0 = informative, 1 = user_retry, 2 = cannot_complete, 4 = cannot_continue. Location-info is the module and function, and Extra-info is the value of parameters and local variables.

I want to make this a standard error handling method that I can put in the library and reuse in all my applications. I mainly use C / C ++ on Linux, but would like to use the resulting library with other languages ​​and platforms.

• The idea is to expand the error type array to indicate some default behavior for a given severity level, but if it then becomes the action taken and does not give any user?

• Or: should such an extension be a sub-array of options that the user needs to select? The problem with this is that the options need to be generalized related to programming, which can very well deform the end user.

• Or: should each application using the error-lib procedure go through its own error array or default behavior - but this will defeat the purpose of the library ...

• Or: if gravity levels will be processed in each application?

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

Answer 1

How you handle errors really depends on the application. A web application has a different error-crash mechanism than a desktop application, and both are very different from an asynchronous messaging system.

Moreover, the general practice of error handling is to process it at the lowest possible level with which it can be solved. This usually means an application level or graphical interface.

I like gravity levels. You may have a pluggable error collection library with various error providers and a severity provider.

Output providers can include things like logginProvider and IgnoreErrorsProvider. Severity providers are likely to be implemented in each project, since severity levels are usually determined by the type of project in which it occurs. (For example, network connectivity problems are more complex for a banking application than for a contact management system).