Hi all,
I'd prefer a more Java-like handling. There it's best practice not to
throw server-exceptions straight through. You'll the server-exceptions
in the server-routines. There you'll generate new client-exceptions,
which are thrown to the client, so there is only one specific type of
exceptions thrown from the server to the client.
In our way working with the ZF I use a way like catching db-exceptions
in the source, handling them to avoid total errors (usage of
backup-sources, retrying soap-queries and so on). If backup-variant also
fails, I throw an Generic_Lymp_Exception, which will be caught in the
bootstrap-file. With this, I'm able to show only the Exceptions I want
to show - I don't want to show the content of any db-exceptions, so I
throw another one, which will then displayed in an user-friendly way.
Matthias
Allard Buijze wrote:
Hi Ralf, all,
exception handling is a very difficult issue, where everyone has a
different opinion.
The most important thing you have to ask yourself is what you want to
do when an exception occurs. In the case of a database access related
exception, you could either display an error page, or access some
other (backup) datasource to get the data.
In de latter case, you'd want to catch the exception as early as
possible, because you want to continue the normal program flow after
retrieving your backup data.
In the first case, there will probably be as much opinions as
developers. You could catch the exceptions in your controller, prepare
an errorpage and diplay that one instead of the page you'd normally
show.
An alternative could be to catch *all* exceptions in your bootstrap
file and display a static error page (which is safer in case your ZF
is really messed up).
My opinion is that it is probably best to do both. Catch all
exceptions you expect in your controller and diplay an error view in
that case. All exceptions that are uncatched at bootstrap level will
then result in a nice error page (if you could even call an error page
"nice") to the user. Don't forget to log the error though, you'd
probably want to know what's wrong.
This is more or less how we do exception handling here at my project
at KLM (Royal Dutch Airlines).
With regards,
Allard Buijze
On 10/24/06, Ralf Eggert <[EMAIL PROTECTED]> wrote:
Hi,
I am still looking for the best way how to handle exceptions and errors
within an application based on the Zend Framework.
What I understood is that all Zend Framework components throw an
exception when a problem occured and don't return false or use
trigger_error(). So, when I extend any component I should do the same.
For example if I extend Zend_Db_Table and add a check to the insert()
method that all required fields are filled, then I should also throw an
Zend_Db_Table exception rather than returning false. Please correct me
if I am wrong here.
So, whenever I use a Zend Framework component I should add a try-catch
block around the code that uses the component. For example:
try {
$user->insert($data);
} catch (Zend_Db_Exception $e) {
// handle error
$error = $e->getMessage();
}
Now I could print out the error to the screen or do whatever. Please
correct me if this is bad practice.
What I am not quite sure about is how to handle exceptions which occur
in the controller or dispatcher correctly. The probably need to be
catched in the bootstrap file. Should I then use my view object to print
out a basic error page or is there a better way?
Thanks for your feedback.
Best Regards,
Ralf
