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.
error handling design is tough
Moderator: General Moderators
for starters take a look at http://java.sun.com/docs/books/tutorial ... tages.html
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?
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.Jenk wrote:...Do you mean methods of raising exceptions, logging error messages, 'safe' error messages, and so on?
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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:
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.
(#10850)
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.)
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.):
And I also have a method for generating an error, but no exception:
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.)
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');Code: Select all
$error->logException(new Exception(''), 'User Friendly Error Message');Code: Select all
$error->createMessage('User Friendly Message');