php5.handling errors. customers/user perspective

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

php5.handling errors. customers/user perspective

Post by jmut »

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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

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.
(#10850)
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post by jmut »

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.
die() message is not an option here. We talk about a "user friendly" messages only.

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?
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

jmut wrote:die() message is not an option here. We talk about a "user friendly" messages only.
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.
Either redirect or forward -- you probably want to support both and most controllers do.
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?
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.
(#10850)
Post Reply