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 <mz no-root.de> 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 <mzno-root.de> 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 <r.eggerttravello.de> 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
> >> >>
> >>
>
|