Refactor error messages and error handling

Amount of code changes

The error handling goes through the whole application. So a refactoring of all places at once is just not possible.

With this issue we enhance the error handling infrastructure.

In addition we adjust all errors in import and export process only, so these kinds of errors can be communicated correctly through the REST API and to the user. All other errors are going to be changed in normal maintenance work, when the need pops up.

New ErrorLogging facility

Since we don't change all the code at once, the old logger must remain for the legacy code. Also the current Logger can not be enhanced easily, so a new logger must be created.

The new logger is stored in the Zend_Registry and respects different error / debug levels, and multiple receivers for error emails.

Basically the error messages are getting logged into a logging table. Only debug data goes still into the error_log.

The current ErrorHandling will be refactored and cleaned up as needed for the introduction of the new Logger.

The ErrorCollect stuff will be removed completely, since all trigger_error calls must be refactored to exceptions.

Introducing ErrorCodes

Each error will be enabled to get an unqiue identifier. This enables identification of similar errors in a specific time and makes support easier. The plain text error description (exception message) will remain also in the code, so the source code remains self explainable.

Same errors at different places will get different error numbers to be able to identify the code point.

In addition a wiki page will be created where all error codes are listed and can be explained. This also improves support and the list is the base for the developers which error code is already used.

A script in the build process will check the error codes from the wiki page against the error codes in the application. No errorcode should be missing or be doubled on each side.

 

Refactoring Exceptions

Currently just a few different exception types are used. This must be changed at the place where exceptions are thrown.

On creating an exception the following data must be given to the exception:

• The error code
• The error message
• The error level of that exception (defined as default in the exception)

The logged error area (see below) is given by the exception type. This type is internally defined in the exception: core, import, export, plugin, etc.

Exceptions can get optional additional information: An error message displayed to the user and debugging data. That error message can be changed via the default translation mechanisms. Only errors which are made to be shown to the user should be translated.

Debugging data and the whole trace of the levels above info are always logged to the error_log.

Debugging data for level debug/trace/info errors are only logged if logging is in one of that levels.

Logging Configuration

It can be configured which errors are logged into the logging table. The logging level is configured for either all areas but can be also set for single areas. The logging configuration should be set by default to warn.

E-Mail Logging Configuration

Multiple receiver addresses can be defined, for each address can be configured the default error level which should be sent to that address. Additionally each area can be set differently for each address.

Logging table

 Most rows of the above table is self explaining.

Other Todos

Refactor the relais errors from application/modules/editor/Models/Import/SegmentProcessor/Relais.php so that not 1000 emails are generated, but one summarizing all relais errors. Already done in another issue to prevent mail bombs.

Improve Workflow Logging so that it is easily reproducible why actions / notifications are triggered or not. Basicly track who is editing TaskUsserAssoc with which parameters.

More descriptive exceptions: Example with missing rights (user hierarchy etc) it is possible to get a ZfExtended_Models_Entity_NoAccessException on opening a task. There is no info about why there is no access.

editor_Plugins_MatchAnalysis_Analysis errors in language resource communications must be logged too (and communicated to the user)

include the installation version number into the error messages

Error Messages should be creatable via the frontend (only with valid session). This enables us to log from the GUI into the DB. This could be necessary in some cases, since therootcause is only usefol for log exceptions. But for debugging it may be necessary to log down other content from the GUI. (For example URLs which produce an Ajax timeout).

Der Http Logger ein ausschaltbar, perspektivisch alle aktuellen Debug Statements durch den logger ersetzen