Proper Error Handling

[Michael Johnson]

Rather than passing strings around, we should implement proper error handling so we can return correct HTTP error codes to the client and a nicely formatted error message. This may involve an explicit view instance to set the response code rather than relying on the View Response listener.

[Michael Johnson]

Note that by proper error handling, I'm thinking of making custom exceptions.

[Ratan Dhawtal]

Good idea!

We could use a class which contains all the exceptions. Parser -> custom exception class -> symfony.

The parser could make a request to custom exception class which makes the request with symfony. Then the result will return to the custom exception class. If there is a problem or a exception occurred it will return the error but we need probably a fixed string which the requester checks, if the result contains this string it will skip everything and result the error code. (This can be implemented at the controllers)

I really think this isn't the best solution. Do you know a better idea then this?

[Michael Johnson]

It looks like the proper way in Symfony would be to create a custom exception interface that handles the various exceptions we want to throw. It might also be useful in that we can still use the implicit view stuff and only do the explicit view creation in the handler.

BTW, for the error handling, you'd wrap your function in a try/catch block if you wanted to do some kind of handling at the controller level. No need to check for a string when you can just catch the named exception. However, if we're doing a custom exception interface, we should not need to catch the exception.

This isn't high priority, so I'll investigate more later.

[Ratan Dhawtal]

I will leave this you then...