Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ExceptionHTTP CodeDescription / Idea behind
ZfExtended_BadMethodCallException405 Method Not AllowedMeans that the used HTTP Method is not allowed / not implemented.
So a usage makes only sense on the controller level.
ZfExtended_NotAuthenticatedException401 UnauthorizedMeans the the user is not authorized, so in the request there was no information to identify the user.
This error should redirect the user in the GUI to the login page.
ZfExtended_NotFoundException404 Not FoundIs used in application routing, is thrown when the whole requested route is not found (invalid URL).
ZfExtended_Models_Entity_NotFoundException404 Not FoundIs used if an entity can not be found (if it is loaded via an id or guid)
ZfExtended_NoAccessException
ZfExtended_Models_Entity_NoAccessException
403 Forbidden

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.

TODO new Unprocesseable Entity Exception
(or reuse ValidateException?)
ZfExtended_UnprocessableEntityException::createResponse
422 Unprocessable Entity

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_Models_Entity_Conflict409 ConflictShould be used if the status of the entity does prevent normal processing: The entity is locked, the entity is used/referenced in other places.
In other words: the entity it self is reasonable that the request can not be processed.

ZfExtended_VersionConflictException

409 ConflictMust only be used if entity can not be saved due a changed entity version. The classical usage of the 409 HTTP error: the entity was changed in the meantime.
ZfExtended_BadGateway
TODO implement 504 Gateway Timeout
502 Bad GatewayShould be used if our request calls internally a third party service, and the third party service or the communication with it does not work.
ZfExtended_ValidateException422 Unprocessable EntityUse this exception if the given data in the request can not be validated or contains non processable data.
ZfExtended_FileUploadException400 Bad RequestTODO, currently not used. Should be used in the context of errors with uploaded data
ZfExtended_Models_MaintenanceException503 Service UnavailableOnly usable in the context of the maintenance mode
ZfExtended_Models_Entity_Exceptions_IntegrityDuplicateKeyTODO → specific exception? No direct HTTP codeIs thrown on saving entities and the underlying DB call returns a "integrity constraint violation 1062 Duplicate entry" error:
That means an entity with such key does already exist (entities with additional unique keys, customer number or user login).
ZfExtended_Models_Entity_Exceptions_IntegrityConstraintTODO → specific exception? No direct HTTP code

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

...