...

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

In the Sdlxliff fileparser editor_Models_Import_FileParser_Sdlxliff_Exception are thrown. In general fileparser code editor_Models_Import_FileParser_Exception should be used.

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

Image Removed

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.

This Exceptions are intended not to be caught, since they transport information to the Caller.
But of course they can be caught if needed and handled differently.

...

The user (authenticated or not) is not allowed to see / manipulate the requested resource.
This can be either by missing ACLs, or missing other preconditions disallowing the request.
In difference to 422 and 409: the authenticated user is the reason why the request can not be processed.

TODO: clear the difference between both exceptions.

...

Should be used PUT/POSTed content does prevent normal processing: Wrong parameters, missing parameters.
In other words: the requested call and its data is reasonable that the request can not be processed.

...

ZfExtended_VersionConflictException

...

Is thrown on saving/deleting entities and the underlying DB call returns one of the following "integrity constraint violation" error:

• 1451 Cannot delete or update a parent row: a foreign key constraint fails → the to be deleted entity is used via foreign key, and may not deleted therefore.
• 1452 Cannot add or update a child row: a foreign key constraint fails → the to be saved foreign entity does not exist (anymore)

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.

That is indeed not the case for errors which should unlikely not happen, there a default english message is enough.

Therefore on exception creation we have to decide if:

1. the error message is shown to the user in a usual dialog (for example if a new user is created where the loginname is already in use)
   and therefore the user can change something to retry the request
2. the error can not be changed by the user (or it is a very seldom situation), there the message is left in english.

This results in two different ways how semantic exceptions are produced:

• 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.

Handling of such exceptions:

...

See the following page for the usage and the idea behind exceptions in translate5.

EventCodes

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

...