Hello Elisamuel,
First, should you ever display exception text directly to a user? Or are
you looking at writing it to operational logs for investigation by those
that would like to see messages in a familiar language? If you are talking
about the latter, the model of replacing text based on the text of the
exception is fragile as it could change or be unpredictable. Some other
solution would need to be found where alternate languages are supported down
to the core of the framework for all things string-like.
Back to my first question, in displaying errors to your users you probably
want to say things like "this order could not be placed due to a system
error, please try back later. The error has been reported to our internal
operations group for resolution." and then have the actual exception go to
an alert log. The business logic error is better to report than "database
exception, invalid trigger" which means nothing useful. Your application
code knows better what the user was attempting than any generic exception
handler or exception class.
--j
On 5/20/06 9:58 PM, "Elisamuel Resto" <
[hidden email]> wrote:
> Do the exception classes of the different components in the Framework
extend a
> base exception class? that would be the easiest route to this
path. One would
> intercept the exception message before it is expelled
for display and
> translate it for display thereafter.
On 5/20/06, Shekar C Reddy
> <
[hidden email]> wrote:
>
> What I was also asking was how do I display a
> language-specific error
> message (I18N) for an exception such as the ones
> below that was thrown in
> the framework:
>
> throw new
> Zend_Db_Adapter_Exception('Invalid fetch mode
> specified');
> throw new
> Zend_Db_Exception('Configuration must be an
> array');
>
> Currently, I'm able
> to translate only the error messages that I throw in my
> code but not the
> errors thrown from inside the framework. Use
>
> set_exception_handler()?
>
>
>
>
>
> On 3/17/06, Mislav
> <
[hidden email]> wrote:
> >
> > When you catch an Exception, you
> can print it out or log it the way you
> want using its public methods.
> Especially helpful is the getTrace() method
> from which you can pretty-print
> where the exception was thrown.
> >
> > You subclass the Exception classes
> just as you would any other class...
> But subclassing makes sense only in
> your own code, you can't to anything to
> change exceptions thrown in other
> people's code. You can just catch them and
> echo them (or better, log them)
> as I said.
> >
> > You may want to implement the magic __toString() method in
> your Exception
> subclasses...
> >
> >
> >
> >
> > On 3/17/06, Shekar C Reddy
> <
[hidden email] > wrote:
> > >
> > > Apparently, exception classes are
> stubs meaning they might dump the
> getMessage() at runtime. Is there a way to
> customize a generic message (in
> layman terms) to display in production
> instead of a technical error message?
> How do I subclass exception classes?
>
> >
> >
>
>
Locked
