Re: [fw-general] Handling exceptions and errors

[Matthias Zitzmann]

Hi Allard, hi all

in my opinion it makes sense to control which information are thrown to 
the outside world (the user). With this way of handling them, I'm able 
to do this - and also I'm able to react on errors when they rise. I also 
use exceptions in my programm logic - so I throw an exception in my 
login-class if the user cannot be authenticated.
Maybe it's a kind of 'overdriven', but I like exceptions
To your tipp not to show exceptions to the user:  that's exactly the 
point, why I catch the programm exception and throw another one - so I'm 
able to control, what the user will get. But I also show the errors in a 
well-formatted way on an error page.


Greets

Matthias

Allard Buijze wrote:
Matthias,

do I understand this right? You catch one exception, just to throw 
another?

The Java-way of exception handling (runtime vs checked exceptions) is
under heavy fire. Especially the checked exceptions (exceptions that
MUST be either catched or explicitly rethrown) aren't making lots of
friends.

I'd say: lets make advantage of the fact that you do not HAVE to
handle exceptions in PHP at every point in code and let the exception
move up your code until the time is right to catch it.

I really do not see the point in rethrowing another exception, since
all exceptions extend from "Exception". So, by catching this one, all
exceptions are catched and can be presented in a peaceful way to you
visitor. If you want a special errorpage saying "sorry, DB is down",
just catch Zend_Db_Exception (or something similar) first and
Exception afterwards.

Another tip: NEVER show the contents of you exceptions to your users.
A stacktrace will scare most users away.

Regards,

Allard

On 10/24/06, Matthias Zitzmann <[EMAIL PROTECTED]> wrote:
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
>>