Page 1 of 1

error handling design is tough

Posted: Wed Nov 22, 2006 9:44 am
by jmut
The more I write code the more I feel like error handling is the hardest part of it all.
When in design to start implement error handling? What to show customers? At which layer to do the error handling? Handling errors of other services?
If all is taken into account and whole error handling is made code gets to grow twice as big and becomes very hard to follow.

So this I guess is a huge topic to discuss.
Is there some books or good matirials on this issue? Most stuff/books that I have read about software design kind of skip the tips & tricks of this matter...the design part of error handling.

Posted: Wed Nov 22, 2006 9:57 am
by volka

Posted: Wed Nov 22, 2006 10:15 am
by Jenk
I'm not sure what you mean by error handling design.. as each error is pretty much unique to every circumstance, thus there isn't a huge amount to talk about, as it will be irrelevant to the next man's situation.

Do you mean methods of raising exceptions, logging error messages, 'safe' error messages, and so on?

Posted: Wed Nov 22, 2006 11:33 am
by jmut
Jenk wrote:...Do you mean methods of raising exceptions, logging error messages, 'safe' error messages, and so on?
yes.... Taking the example with exceptions... about generating diff type of exceptions, possibly use exceptions codes etc.

Theoretically it all sounds straight forward...I guess the key is to just separate distinct actions logically. For example adding customer
will include adding payment data, personal preferences etc..and actually try catch just addCustomer() method.

Posted: Wed Nov 22, 2006 1:49 pm
by Christopher
I find that error handling gets worse the more you think about it ... so I try not to think about it so much. :)

The main problem is that it is not just one thing:
  • - There are user errors that need view specific messages like a form field input error
    - There are user errors that can have a generic error page like a "Your browser does not support Javascript" error.
    - There are internal errors that need a alternate view like when now records are return from a query to list information.
    - There are internal errors that can use a generic view like when the DB server has died an the app cannot connect.
There are many others. It really depends on whether there is anything the program can do about the error, as well as if there is anything the user can do about the error.

Posted: Thu Nov 23, 2006 3:21 am
by Jenk
Right, had a bit of a think about this one..

How I handle errors:

I have an error handling object. No big surprises there.

The class changes form for nearly every application but the interface is relatively the same throughout.

I have a method for logging the error and ceasing the application. (More than just 'die', I use observers to notify the various objects the application is closing, etc.)

Code: Select all

$error->kill(new Exception(''), 'User Friendly Error Message');
I have a method for logging the exception, generating an error, but not ceasing the application (message is optional - if none passed usually no error for the user, only log the exception.):

Code: Select all

$error->logException(new Exception(''), 'User Friendly Error Message');
And I also have a method for generating an error, but no exception:

Code: Select all

$error->createMessage('User Friendly Message');
For the controller to know if there is any errors, I have the boolean $error->hasErrors();, and a sub-template for the error message box. The kill() method will use it's own template and rendering, as usually if I need to kill() the view and/or model will be unavailable (otherwise I won't kill.)