Re: [exceptions] Generic error messages

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [exceptions] Generic error messages

Shekar C Reddy
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?


Reply | Threaded
Open this post in threaded view
|

Re: [exceptions] Generic error messages

Elisamuel Resto
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?
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [exceptions] Generic error messages

Jayson Minard (ZF)
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?
>
> >
> >
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [exceptions] Generic error messages

Elisamuel Resto
Hello Jayson,

Please don't mind me, I was really sleepy and my client didn't link
the other messages in the thread, so I only saw the last message
before mine, hence the answer. Sorry for that!

-Samuel

On 5/22/06, Jayson Minard <[hidden email]> wrote:

> 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.
>