...

Wording

Since not only errors are logged, instead of "Error" or "ErrorCodes" we are talking about "Event" and "EventCodes" in the context of logging.

In the context of Exception "error" can be used, since exceptions are errors.

Basic Class Architecture

Logger itself

DebugLevels

The following levels are defined as class constants  prefixed with LEVEL_ in ZfExtended_Logger class:

ZfExtended_Logger

• The logger itself. Methods of that class are used to log custom messages / data and exceptions / errors.
• A reusable default instance is located in the registry: Zend_Registry::get('logger');
• The default instance is initialized via the Resource Plugin ZfExtended_Resource_Logger and is therefore configured from the .ini configuration system as other Zend Resources too.
  • Own instances with custom configuration can be instanced when needed
  • The default instance is also accessible via Zend getResource stuff
• A Logger instance can have multiple writer instances which writes the received log messages to different targets - as configured.
  • One can also define additional Logger instances if needed with a different config as the default one

• provides functions like fatal, error, warn, info, debug, trace for direct log output

• provides a function exception to log exceptions, this is automatically invoked in the final exception handler but can also be used manually for catched exceptions, which have to be logged but should not stop the request then.

...

// use the default logger instance:
$logger = Zend_Registry::get('logger');
/* @var $logger ZfExtended_Logger */
$logger->info('E1234', 'This is the message for the log where {variable} can be used.', [
	'mydebugdata' => "FOOBAR can be an object or array too",
    'variable' => "This text goes into the above variable with curly braces",
]);

ZfExtended_Logger_Event

• A container class for the event information.
• Is used internally to communicate the event from the logger to the different writers.

Log Writers

A ZfExtended_Logger can have multiple instances of writers. The writers are responsible for filtering (according to the configuration) and writing the log message to the specific backend.

So each writer can have a different filter configuration, one can configure one writer to listen on all import errors on error level debug and send them to one address, another writer can listen to all events on level > warn to log them as usual.

ZfExtended_Logger_Writer_Abstract

Abstract class for each specific writer.

ZfExtended_Logger_Writer_Database

• Logs the received events into the central log database table Zf_errorlog.
• This Writer can be configured with additional writers again, which receive events only once. All repeated events are stored in the database, but for example a email is send only once.

ZfExtended_Logger_Writer_DirectMail

Sends the event directly to the configured email address. No repetition recognition of events (spam protection) is done here.

ZfExtended_Logger_Writer_ErrorLog

Writes the events to the error_log configured in PHP.

ZfExtended_Logger_Writer_ChromeLogger

Writes the events to the chrome developer toolbar JS log. The Addon "Chrome Logger" must be installed therefore in the browser.

Recommended not to be used in production environments!

editor_Logger_TaskWriter

translate5 specific writer which logs all events with a field "task" containing a editor_Models_Task instance in the extra data to a special task log table.

editor_Models_Logger_Task extending ZfExtended_Models_Entity_Abstract and editor_Models_Db_Logger_Task extending Zend_Db_Table_Abstract are used to save to and load from the task log table.

Configuration of LogWriters

The configuraton of log writers can be either done in the application.ini / installation.ini or hardcoded in PHP.

...

// use the default logger instance:
$logger = Zend_Registry::get('logger');
$logger->addWriter('name', $writerInstance);

Filtering

Each writer can have an list of filter rules. See the above module.ini example. The filter rules are connected via "or", that means one of the filter rules must be valid in order that an event  is logged.

...

Logging Database Tables

Currently there are two database tables receiving events:

...

-- instead of 
select * from Zf_errorlog;
-- use for better readability:
select * from Zf_errorlog\G

Exceptions

In translate5 to less different exception types were used till now. Mostly just a ZfExtended_Exception was used.

To be more flexible in filtering on logging exceptions but also on internal exception handling with try catch more exceptions are needed.

Examples

editor_Models_Import_FileParser_Sdlxliff_Exception extends editor_Models_Import_FileParser_Exception extends ZfExtended_ErrorCodeException

...

Since in FileParsing many errors can happen, a fine granulated exception structure is needed. In other code places this is not the case. At least one own Exception per Plugin / Package.

Internal Exception Structure

Each exception contains the mapping between the used event code and the related error message string. Since we are in an exception we can talk here about errors and not generally about events.

class editor_Models_Import_FileParser_Sdlxliff_Exception extends editor_Models_Import_FileParser_Exception {
    /**
     * @var string
     */
    protected $domain = 'editor.import.fileparser.sdlxliff';  //the domain (origin) string for hierarchical filtering
    
    static protected $localErrorCodes = [              //the error (event) codes used by that exception
        'E1000' => 'The file "{filename}" contains SDL comments which are currently not supported!',
        'E1001' => 'The opening tag "{tagName}" contains the tagId "{tagId}" which is no valid SDLXLIFF!',
        'E1003' => 'There are change Markers in the sdlxliff-file "{filename}"! Please clear them first and then try to check in the file again.',
		// [...] more mappings
    ];
}

Exception usage

if ($shitHappened && $itWasMyFault) {
	//There are change Markers in the sdlxliff-file which are not supported!        → there should be a brief comment to explain what is going wrong
    throw new editor_Models_Import_FileParser_Sdlxliff_Exception('E1003', [		 // → The exception receives just the EventCode and an array with extra data
        'task' => $this->task,
        'filename' => $this->_fileName,
    ]);
}

Exception Hierarchy and way to the frontend

Generic Exceptions

For the handling / catching of such exceptions see the section "Examples for specific Exceptions" below.

...

Exceptions with Semantic

This exceptions are used to answer errors to the API in REST full way, by transporting semantic as HTTP response code.

...

Creation of exceptions static method createResponse

One fundamental problem for development in translate5 is that the default GUI language of translate5 is german, but most of the error messages are in english.
At some places the error message is intended to be used directly as user feedback, therefore the error message must be also in german at that place and the message must go through the internal translation mechanism before send to the user.

...

• the default constructor, all data must be given as usual.
• the static method getResponse which creates a new exception instance prefilled with the given error messages in the users GUI language

Examples for specific Exceptions

This exceptions are used in the case of errors in the application.

...

EventCodes

The EventCodes used in exceptions and other logging usages are defined via the ErrorCodes listed and maintained in confluence..

Domains

The domains are used to classify and therefore filter exceptions and log entries.

...

Three starting domains are defined so far: "editor" for the editor module, "core" for core code, "plugin" for plugin code.

Domain Examples:

editor.customer                 ./application/modules/editor/Controllers/CustomerController.php

...

editor.import                   ./application/modules/editor/Models/Import/Exception.php

Use the logger facility just to log stuff

The default logger instance is generally available in the registry:

$log = Zend_Registry::get('logger');
/* @var $log ZfExtendend_Logger */
$log->error("TODO"); // logs an error
$log->logDev($data1, $data2, ...); // a convienent replacement for error_log(print_r($data, 1)); Only for development, should not be comitted!

// the WorkflowLogger - dedicated to translate5 tasks and workflow stuff - must be instanced manually:
// TODO

TODO

Exception Definition / Usage:

...