Hi,
I am gathering some info about how should problems be served to users.
Question is design only..no code involved.
Say your application is database dependent (e.g mysql).
1. Do you consider sql query failure a fatal error?
2. Do you handle fatal errors and how do you present this to users?
3. Maybe what layers/architecture the apliaction consists of so that errors are handled in one place?
How do you generally approach these problems?
I gennerally try to handle every single point where an error might occur which is kind of wrong I thing.
First of all the application gets kind of ugly with all these checks and second of course at some point it is hard to mantain.
I am thinking maybe an observer pattern is good to implement so when an error occurse some object is filled with error info and stuff.
php5.handling errors. customers/user perspective
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Where to put error messages is an old problem. Usually I either see them dealt with immediately or given to a Response object or some kind of Logger for later.
I try to always give the use a normal page with error instructions (no white, text-only error dumps from die()). For fatal errors the instruction is usually to contact techical support -- but I usually have those error conditions log and email me as well.
I try to always give the use a normal page with error instructions (no white, text-only error dumps from die()). For fatal errors the instruction is usually to contact techical support -- but I usually have those error conditions log and email me as well.
(#10850)
die() message is not an option here. We talk about a "user friendly" messages only.arborint wrote:Where to put error messages is an old problem. Usually I either see them dealt with immediately or given to a Response object or some kind of Logger for later.
I try to always give the use a normal page with error instructions (no white, text-only error dumps from die()). For fatal errors the instruction is usually to contact techical support -- but I usually have those error conditions log and email me as well.
So do you make your application so you have a single workflow with one exit or you rather make redirect("error_page");exit();
and hence have multiple end points in an application.
As for mailing problems....would that not be a spam issue if multiple clients encounter this issue. Are you taking some measures to receive some type of error once only (in given period of time) to prevent spam to yourself?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I usually only do that to catch infrequent conditions -- so I have not had that problem. Something like the database server being down would be dealt with upon connection.jmut wrote:die() message is not an option here. We talk about a "user friendly" messages only.
Either redirect or forward -- you probably want to support both and most controllers do.jmut wrote:So do you make your application so you have a single workflow with one exit or you rather make redirect("error_page");exit();
and hence have multiple end points in an application.jmut wrote:As for mailing problems....would that not be a spam issue if multiple clients encounter this issue. Are you taking some measures to receive some type of error once only (in given period of time) to prevent spam to yourself?
(#10850)