Matthias, all,
I think I misunderstood your first mail. If I understand it right, you
just rethrow an exception so that you can "filter" the actual error
into a user friendly error? I can see the point in doing that, as long
as you don't have to add the same description in multiple locations...
(e.g. in each controller that uses a DB connection).
Perhaps it is a good idea to start a "best practices" section
somewhere in the wiki or even the manual. I think lots of people are
unaware of the the power of exceptions. Anybody have an idea?
Regards,
Allard
On 10/26/06, Matthias Zitzmann <[EMAIL PROTECTED]> wrote:
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
>> >>
>>
