Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 7:34 PM, Gary . wrote: > On Tue, Apr 27, 2010 at 10:46 AM, Peter Lind wrote: >> On 27 April 2010 10:42, Gary . wrote: >>> How do you guys handle errors during, say, db insertions. >>> >>> Let's say you have an ongoing transaction which fails on the n-th >>> insert. Ok, you roll back the transaction, no problem. How do you then >>> inform the user? Just using the text from pg_result_error or >>> something? >>> >> >> If it's a normal user, give them some info about what went wrong but >> not the specific error returned. > > Yeah. I know :( Originally I couldn't find a "nice" way of translating > between db errors and "user" errors. The only interface to the db > errors that I could find was the error messages returned from > pg_last_error. Yes, I could have used an array translating between the > the strings returned by pg_last_error or whatever, but *gag* it would > not only have made the code look horrible but would also have been > susceptible to changes in the error messages returned by the db > interface. In the end I changed tack slightly and used pg_send_* and > pg_result_error_field to get a short code I could use as a reference > into an array. thought of adding few extra things i do. i keep a constant to check the running environment. before i do the 'trigger_error' with pg/mysql raised error, i conditionally check whethr it's 'live', 'beta' or 'dev' environment and use different error_handlers. if it's 'production' environment, the error handler will write the detail error with all back-trace and possible sql queries and data into a log file with a unique id, and displays a friendly message with that reference id, so the user can report to sys admin if he/she wishes. ~viraj > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27/04/10 16:37, tedd wrote: Error handling is almost an art form. More like a black art - voodoo perhaps... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 12:23 PM, tedd wrote: > At 4:23 PM +0100 4/27/10, Nathan Rixham wrote: >> >> I'm still shocked you guys are still writing code that has errors in it, >> what's worse is you know about the errors, and instead of fixing them >> you're just telling the user about it! >> >> :p > > Here's my code that doesn't contain errors: > > > ?> > > Cheers, > > ted > > -- > --- > http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Watch out for that new warning message: Warning: Deadbeat script. Your code does not do anything useful in teddscript.php on line 1 :-) Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 4/27/10, tedd wrote: > At 4:23 PM +0100 4/27/10, Nathan Rixham wrote: >> >>I'm still shocked you guys are still writing code that has errors in it, >>what's worse is you know about the errors, and instead of fixing them >>you're just telling the user about it! >> >>:p > > Here's my code that doesn't contain errors: > > > ?> Wow! What license are you applying to that? Can I re-use it without fear or being sued for copyright infringement? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Error handling strategies (db related)
At 10:24 AM -0400 4/27/10, Paul M Foster wrote: >Unfortunately, true. Sometimes I think computer users should be >required to take a course in using a computer before being allowed >behind the keyboard. > >Paul I came across a term long ago amidst my readings: PEBKAC Problem Exists Between Keyboard And Chair Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 12:12:31PM -0400, tedd wrote: > At 4:13 PM +0200 4/27/10, Peter Lind wrote: >> If only the world consisted of smart users ... I think, however, that >> we're generally closer to the opposite. And no, I don't hate users - >> I've just seen too many people do things that were very far removed >> from "smart". >> >> Regards >> Peter > > Peter et al: > > Smart is a relative term. I have one account where the majority of > users are PhD's -- and they indeed have the "smarts" and the > sheepskins to prove it. > > You would be surprised as to how many of those forget their logons > and insist that they did not enter their logons as they were > recorded. For example, I had one user (i.e., fictitious Mary Smith) > who said that "marysmith" was not her logon because she always uses > "msmith" for all her logons -- but that was what was recorded in the > database. > > I tried to explain to her that the database doesn't make this stuff > up, for example how would the script know to use "marysmith" for her > logon if she had not provided it? But somehow it was the script's > fault for not knowing she always uses "msmith". Keep in mind these > are people with PhD's. I have many other stories. There's the problem right there. PhD egos. Seen it before. In my company, we deal with a lot of doctors. For us, that means chiropractors, dentists, veterinarians, optomotrists and the like. Who we don't deal with is doctors of the MD variety. They are way too arrogant, and their staffs typically back that claim up. The few times we've dealt with them, it's always been a disaster. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, 2010-04-27 at 12:31 -0400, tedd wrote: > At 5:09 PM +0100 4/27/10, Ashley Sheridan wrote: > >> > > > >Sounds like you've got a few stories that would a lot of people > >happy were you to share them on the DailyWTF ;) > > > >Thanks, > >Ash > > Ash: > > Sharing them here is more direct and meaningful to what we do, but I > will investigate what you suggest. > > Cheers, > > tedd > I've just spent my last weeks worth of spare time looking at the last few years of posts on that site, and the IT and programming related ones just make me chuckle! Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Error handling strategies (db related)
At 5:09 PM +0100 4/27/10, Ashley Sheridan wrote: Sounds like you've got a few stories that would a lot of people happy were you to share them on the DailyWTF ;) Thanks, Ash Ash: Sharing them here is more direct and meaningful to what we do, but I will investigate what you suggest. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 18:21, tedd wrote: > At 4:31 PM +0200 4/27/10, Peter Lind wrote: >> >> While I love to rant at stupid users, the truth is probably that >> programmers are the ones who should take courses in how users think. >> In the end, if I fail to understand my users, it doesn't matter how >> great my program is: they'll still fail to use it. Anyway, those are >> just truisms :) Nothing new under the sun. >> >> Regards >> Peter > > > Peter: > > You're right on. I just read three books on the subject: > > 1. "Don't Make Me Think" by Steve Krug. > > This is a somewhat dated book, but his perspective is "right-on" and is the > basis for understanding usability. +1. Great book that is. > 2. "Neuro Web Design" bu Susan M. Weinschenk". > > The theory behind why people do what they do is explained in great detail in > this book. It makes a great book to read regardless of if you're trying to > sell something on the net or elsewhere. However, this book is focused on > selling things to people via the net. Will have to look at that, sounds interesting. > 3. "Rocket Surgery Made Easy" by Steve Krug. > > This is the second book in Steve's "How to do it yourself" in usability > studies. It will give you exactly what you need to do to set up inexpensive > usability studies. Usability studies are important in software and web > design. > > If developers (and clients) read those books, we would have less problems > dealing with users. > Haven't read his second, guess I should :) Thanks for the recommendations. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
At 4:23 PM +0100 4/27/10, Nathan Rixham wrote: I'm still shocked you guys are still writing code that has errors in it, what's worse is you know about the errors, and instead of fixing them you're just telling the user about it! :p Here's my code that doesn't contain errors: Cheers, ted -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
At 4:31 PM +0200 4/27/10, Peter Lind wrote: While I love to rant at stupid users, the truth is probably that programmers are the ones who should take courses in how users think. In the end, if I fail to understand my users, it doesn't matter how great my program is: they'll still fail to use it. Anyway, those are just truisms :) Nothing new under the sun. Regards Peter Peter: You're right on. I just read three books on the subject: 1. "Don't Make Me Think" by Steve Krug. This is a somewhat dated book, but his perspective is "right-on" and is the basis for understanding usability. 2. "Neuro Web Design" bu Susan M. Weinschenk". The theory behind why people do what they do is explained in great detail in this book. It makes a great book to read regardless of if you're trying to sell something on the net or elsewhere. However, this book is focused on selling things to people via the net. 3. "Rocket Surgery Made Easy" by Steve Krug. This is the second book in Steve's "How to do it yourself" in usability studies. It will give you exactly what you need to do to set up inexpensive usability studies. Usability studies are important in software and web design. If developers (and clients) read those books, we would have less problems dealing with users. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, 2010-04-27 at 12:12 -0400, tedd wrote: > At 4:13 PM +0200 4/27/10, Peter Lind wrote: > >If only the world consisted of smart users ... I think, however, that > >we're generally closer to the opposite. And no, I don't hate users - > >I've just seen too many people do things that were very far removed > >from "smart". > > > >Regards > >Peter > > Peter et al: > > Smart is a relative term. I have one account where the majority of > users are PhD's -- and they indeed have the "smarts" and the > sheepskins to prove it. > > You would be surprised as to how many of those forget their logons > and insist that they did not enter their logons as they were > recorded. For example, I had one user (i.e., fictitious Mary Smith) > who said that "marysmith" was not her logon because she always uses > "msmith" for all her logons -- but that was what was recorded in the > database. > > I tried to explain to her that the database doesn't make this stuff > up, for example how would the script know to use "marysmith" for her > logon if she had not provided it? But somehow it was the script's > fault for not knowing she always uses "msmith". Keep in mind these > are people with PhD's. I have many other stories. > > As I see it, one of the problems we face as developers is confronting > user's egos. They have an image of themselves and our scripts can > threaten that image by making them feel ignorant. We have to deal > with that in a way that informs them, but doesn't demean them in any > fashion. > > Here's a real world example -- over 20 years ago a company made an > electronic hand-held chess game. > > While the game was successful, the company received a considerable > amount of repairs, way over what they had expected. They wanted to > find out why and after an investigation they found that their > software made the computer's chess-moves TOO quickly. So, they place > a time delay into the software so that it would "look" to the user > like the computer was thinking about its moves. That time-delay > solved the problem. > > Apparently, some end-users got pissed when they thought the computer > could so easily beat them. But, if the computer took more time to > beat them, then that was more acceptable and the end-users were less > inclined to throw the game into a wall. > > So with respect to software engineering, how users view what's going > on is important. > > Cheers, > > tedd > > -- > --- > http://sperling.com http://ancientstones.com http://earthstones.com > Sounds like you've got a few stories that would a lot of people happy were you to share them on the DailyWTF ;) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Error handling strategies (db related)
At 10:24 AM -0400 4/27/10, Paul M Foster wrote: Unfortunately, true. Sometimes I think computer users should be required to take a course in using a computer before being allowed behind the keyboard. Paul Yeah, like I believe that everyone should do through at least one divorce before getting married. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
At 4:13 PM +0200 4/27/10, Peter Lind wrote: If only the world consisted of smart users ... I think, however, that we're generally closer to the opposite. And no, I don't hate users - I've just seen too many people do things that were very far removed from "smart". Regards Peter Peter et al: Smart is a relative term. I have one account where the majority of users are PhD's -- and they indeed have the "smarts" and the sheepskins to prove it. You would be surprised as to how many of those forget their logons and insist that they did not enter their logons as they were recorded. For example, I had one user (i.e., fictitious Mary Smith) who said that "marysmith" was not her logon because she always uses "msmith" for all her logons -- but that was what was recorded in the database. I tried to explain to her that the database doesn't make this stuff up, for example how would the script know to use "marysmith" for her logon if she had not provided it? But somehow it was the script's fault for not knowing she always uses "msmith". Keep in mind these are people with PhD's. I have many other stories. As I see it, one of the problems we face as developers is confronting user's egos. They have an image of themselves and our scripts can threaten that image by making them feel ignorant. We have to deal with that in a way that informs them, but doesn't demean them in any fashion. Here's a real world example -- over 20 years ago a company made an electronic hand-held chess game. While the game was successful, the company received a considerable amount of repairs, way over what they had expected. They wanted to find out why and after an investigation they found that their software made the computer's chess-moves TOO quickly. So, they place a time delay into the software so that it would "look" to the user like the computer was thinking about its moves. That time-delay solved the problem. Apparently, some end-users got pissed when they thought the computer could so easily beat them. But, if the computer took more time to beat them, then that was more acceptable and the end-users were less inclined to throw the game into a wall. So with respect to software engineering, how users view what's going on is important. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
Teus Benschop wrote: >> I'm still shocked you guys are still writing code that has errors in it, >> what's worse is you know about the errors, and instead of fixing them >> you're just telling the user about it! >> > > The point here is that we, programmers, know that we write code with > bugs in it. We are realistic about it, that is, we know that perfect > code does not exist, and that there are bugs in it. So what we care > about is to bring this reality to the users in a gracious manner. And > the other thing is that if for example a database is down, that is not > our fault, it is an external error, but this error should be brought to > the user as well. Teus. > had hoped the addition of a (now stripped) :p emote would ensure taking the above as a joke tbh ;) regardless, might I add that exceptions or errors mapped through to the appropriate HTTP status code and a friendly site specific error document may be a good way to proceed. A good example of friendly error documents can be seen at most of the major sites around the web that we all frequent (or are at least aware of). Further, these friendly documents make it clear that the error is a server / application error and that no action the user takes will fix the error. Best, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
At 9:36 AM -0400 4/27/10, Paul M Foster wrote:
On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote:
How do you guys handle errors during, say, db insertions.
Let's say you have an ongoing transaction which fails on the n-th
insert. Ok, you roll back the transaction, no problem. How do you then
inform the user? Just using the text from pg_result_error or
something?
I use trigger_error() and stop execution at that point. I give the user
an error that basically says, "Talk to the admin/programmer". And I send
the programmer a message containing a trace of what occurred. The theory
is that, all things being equal, such an error should never occur and
there is no user recovery. If the user properly entered the data they
were asked for, then the transaction should go through without incident.
If something prevents the transaction from going through, it's likely a
coding problem and up to the programmer or admin to repair.
Paul
+1
I do something similar with the accounts I want to monitor.
For example, when I access the database during development, I use
code similar to this --
// --- script
$sql = "SELECT * FROM users WHERE user_id = $uid ";
$result = mysql_query($sql) or die(report($query,__LINE__ ,__FILE__));
// --
-- and then a "report" function similar to this --
// -- functions
function report($query, $line, $file)
{
echo($query . '' .$line . '' . $file . '' .
mysql_error());
}
// --
This provides me with information as to what happened and where.
When the project goes live (out of development) then I replace the
"report" function with code that can send me an email telling me what
happened (to what domain) as well as an explanation to the user
(screen display and sometimes even email) and sometimes an email is
sent to the client (i.e., the user's credit card was denied for xxx
reason trying to purchase product xxx at this date).
Note, all my error reporting functions are located in a single
function script that is included with every script that has access to
the database. That way I can turn on/off error reporting and make
alterations as to how to handle errors in one file. The difference
between "development" and "live" is a simply a change in one script.
Error handling is almost an art form.
Cheers,
tedd
--
---
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
> I'm still shocked you guys are still writing code that has errors in it, > what's worse is you know about the errors, and instead of fixing them > you're just telling the user about it! > The point here is that we, programmers, know that we write code with bugs in it. We are realistic about it, that is, we know that perfect code does not exist, and that there are bugs in it. So what we care about is to bring this reality to the users in a gracious manner. And the other thing is that if for example a database is down, that is not our fault, it is an external error, but this error should be brought to the user as well. Teus. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
Peter Lind wrote: > On 27 April 2010 16:24, Paul M Foster wrote: >> On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: >> >>> On 27 April 2010 16:07, Paul M Foster wrote: On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > On 27 April 2010 15:36, Paul M Foster wrote: >> On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: >> >>> How do you guys handle errors during, say, db insertions. >>> >>> Let's say you have an ongoing transaction which fails on the n-th >>> insert. Ok, you roll back the transaction, no problem. How do you then >>> inform the user? Just using the text from pg_result_error or >>> something? >> I use trigger_error() and stop execution at that point. I give the user >> an error that basically says, "Talk to the admin/programmer". And I send >> the programmer a message containing a trace of what occurred. The theory >> is that, all things being equal, such an error should never occur and >> there is no user recovery. If the user properly entered the data they >> were asked for, then the transaction should go through without incident. >> If something prevents the transaction from going through, it's likely a >> coding problem and up to the programmer or admin to repair. >> > Fair reasoning, but it amounts to throwing a bucket of cold water in > the face of your user. If I was looking at an error like that, I'd get > mighty annoyed with the software, and after a while would definitely > look for alternatives. Whether or not there's a coding problem, you > have to look at the situation from the point of the user: a complete > failure with no information is like a BSOD/TSOD ... and we all know > the effect they have on a user. I assume (1) that I've vetted the user data and given them the option to repair it if it's faulty; (2) beyond the beta phase, this type of error should not happen. If it does, it's a coding problem. Given that the user can do *nothing* about this and it *is* a coding problem, what would you tell the user? >>> "Sorry, but there was a problem inserting the data into the database. >>> The developers have been notified about this error and will hopefully >>> have it fixed very soon. We apologize for the inconvenience." >>> >>> At the very least, something along those lines. >> Well of course. No reason to slap the user in the face. I agree. But in >> the end, this is about the same as saying, "Talk to the programmer", >> just a nicer way of saying it. > > Of course, it's just a question of degree. If the user can't correct > the error, there's only one person that can: the programmer. Question > is what you tell the user in that situation. > If I was the user, I'd be cranky as well. But if I were a smart user, I'd realize that the programmer made a mistake and put the responsibility firmly on him. And expect him to fix it pronto. >>> If only the world consisted of smart users ... I think, however, that >>> we're generally closer to the opposite. And no, I don't hate users - >>> I've just seen too many people do things that were very far removed >>> from "smart". >> Unfortunately, true. Sometimes I think computer users should be required >> to take a course in using a computer before being allowed behind the >> keyboard. >> > > While I love to rant at stupid users, the truth is probably that > programmers are the ones who should take courses in how users think. > In the end, if I fail to understand my users, it doesn't matter how > great my program is: they'll still fail to use it. Anyway, those are > just truisms :) Nothing new under the sun. I'm still shocked you guys are still writing code that has errors in it, what's worse is you know about the errors, and instead of fixing them you're just telling the user about it! :p -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 16:24, Paul M Foster wrote: > On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: > >> On 27 April 2010 16:07, Paul M Foster wrote: >> > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: >> > >> >> On 27 April 2010 15:36, Paul M Foster wrote: >> >> > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: >> >> > >> >> >> How do you guys handle errors during, say, db insertions. >> >> >> >> >> >> Let's say you have an ongoing transaction which fails on the n-th >> >> >> insert. Ok, you roll back the transaction, no problem. How do you then >> >> >> inform the user? Just using the text from pg_result_error or >> >> >> something? >> >> > >> >> > I use trigger_error() and stop execution at that point. I give the user >> >> > an error that basically says, "Talk to the admin/programmer". And I send >> >> > the programmer a message containing a trace of what occurred. The theory >> >> > is that, all things being equal, such an error should never occur and >> >> > there is no user recovery. If the user properly entered the data they >> >> > were asked for, then the transaction should go through without incident. >> >> > If something prevents the transaction from going through, it's likely a >> >> > coding problem and up to the programmer or admin to repair. >> >> > >> >> >> >> Fair reasoning, but it amounts to throwing a bucket of cold water in >> >> the face of your user. If I was looking at an error like that, I'd get >> >> mighty annoyed with the software, and after a while would definitely >> >> look for alternatives. Whether or not there's a coding problem, you >> >> have to look at the situation from the point of the user: a complete >> >> failure with no information is like a BSOD/TSOD ... and we all know >> >> the effect they have on a user. >> > >> > I assume (1) that I've vetted the user data and given them the option to >> > repair it if it's faulty; (2) beyond the beta phase, this type of error >> > should not happen. If it does, it's a coding problem. Given that the >> > user can do *nothing* about this and it *is* a coding problem, what >> > would you tell the user? >> >> "Sorry, but there was a problem inserting the data into the database. >> The developers have been notified about this error and will hopefully >> have it fixed very soon. We apologize for the inconvenience." >> >> At the very least, something along those lines. > > Well of course. No reason to slap the user in the face. I agree. But in > the end, this is about the same as saying, "Talk to the programmer", > just a nicer way of saying it. Of course, it's just a question of degree. If the user can't correct the error, there's only one person that can: the programmer. Question is what you tell the user in that situation. >> >> > If I was the user, I'd be cranky as well. But if I were a smart user, >> > I'd realize that the programmer made a mistake and put the >> > responsibility firmly on him. And expect him to fix it pronto. >> >> If only the world consisted of smart users ... I think, however, that >> we're generally closer to the opposite. And no, I don't hate users - >> I've just seen too many people do things that were very far removed >> from "smart". > > Unfortunately, true. Sometimes I think computer users should be required > to take a course in using a computer before being allowed behind the > keyboard. > While I love to rant at stupid users, the truth is probably that programmers are the ones who should take courses in how users think. In the end, if I fail to understand my users, it doesn't matter how great my program is: they'll still fail to use it. Anyway, those are just truisms :) Nothing new under the sun. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: > On 27 April 2010 16:07, Paul M Foster wrote: > > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > > > >> On 27 April 2010 15:36, Paul M Foster wrote: > >> > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: > >> > > >> >> How do you guys handle errors during, say, db insertions. > >> >> > >> >> Let's say you have an ongoing transaction which fails on the n-th > >> >> insert. Ok, you roll back the transaction, no problem. How do you then > >> >> inform the user? Just using the text from pg_result_error or > >> >> something? > >> > > >> > I use trigger_error() and stop execution at that point. I give the user > >> > an error that basically says, "Talk to the admin/programmer". And I send > >> > the programmer a message containing a trace of what occurred. The theory > >> > is that, all things being equal, such an error should never occur and > >> > there is no user recovery. If the user properly entered the data they > >> > were asked for, then the transaction should go through without incident. > >> > If something prevents the transaction from going through, it's likely a > >> > coding problem and up to the programmer or admin to repair. > >> > > >> > >> Fair reasoning, but it amounts to throwing a bucket of cold water in > >> the face of your user. If I was looking at an error like that, I'd get > >> mighty annoyed with the software, and after a while would definitely > >> look for alternatives. Whether or not there's a coding problem, you > >> have to look at the situation from the point of the user: a complete > >> failure with no information is like a BSOD/TSOD ... and we all know > >> the effect they have on a user. > > > > I assume (1) that I've vetted the user data and given them the option to > > repair it if it's faulty; (2) beyond the beta phase, this type of error > > should not happen. If it does, it's a coding problem. Given that the > > user can do *nothing* about this and it *is* a coding problem, what > > would you tell the user? > > "Sorry, but there was a problem inserting the data into the database. > The developers have been notified about this error and will hopefully > have it fixed very soon. We apologize for the inconvenience." > > At the very least, something along those lines. Well of course. No reason to slap the user in the face. I agree. But in the end, this is about the same as saying, "Talk to the programmer", just a nicer way of saying it. > > > If I was the user, I'd be cranky as well. But if I were a smart user, > > I'd realize that the programmer made a mistake and put the > > responsibility firmly on him. And expect him to fix it pronto. > > If only the world consisted of smart users ... I think, however, that > we're generally closer to the opposite. And no, I don't hate users - > I've just seen too many people do things that were very far removed > from "smart". Unfortunately, true. Sometimes I think computer users should be required to take a course in using a computer before being allowed behind the keyboard. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 16:07, Paul M Foster wrote: > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > >> On 27 April 2010 15:36, Paul M Foster wrote: >> > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: >> > >> >> How do you guys handle errors during, say, db insertions. >> >> >> >> Let's say you have an ongoing transaction which fails on the n-th >> >> insert. Ok, you roll back the transaction, no problem. How do you then >> >> inform the user? Just using the text from pg_result_error or >> >> something? >> > >> > I use trigger_error() and stop execution at that point. I give the user >> > an error that basically says, "Talk to the admin/programmer". And I send >> > the programmer a message containing a trace of what occurred. The theory >> > is that, all things being equal, such an error should never occur and >> > there is no user recovery. If the user properly entered the data they >> > were asked for, then the transaction should go through without incident. >> > If something prevents the transaction from going through, it's likely a >> > coding problem and up to the programmer or admin to repair. >> > >> >> Fair reasoning, but it amounts to throwing a bucket of cold water in >> the face of your user. If I was looking at an error like that, I'd get >> mighty annoyed with the software, and after a while would definitely >> look for alternatives. Whether or not there's a coding problem, you >> have to look at the situation from the point of the user: a complete >> failure with no information is like a BSOD/TSOD ... and we all know >> the effect they have on a user. > > I assume (1) that I've vetted the user data and given them the option to > repair it if it's faulty; (2) beyond the beta phase, this type of error > should not happen. If it does, it's a coding problem. Given that the > user can do *nothing* about this and it *is* a coding problem, what > would you tell the user? "Sorry, but there was a problem inserting the data into the database. The developers have been notified about this error and will hopefully have it fixed very soon. We apologize for the inconvenience." At the very least, something along those lines. > If I was the user, I'd be cranky as well. But if I were a smart user, > I'd realize that the programmer made a mistake and put the > responsibility firmly on him. And expect him to fix it pronto. If only the world consisted of smart users ... I think, however, that we're generally closer to the opposite. And no, I don't hate users - I've just seen too many people do things that were very far removed from "smart". Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > On 27 April 2010 15:36, Paul M Foster wrote: > > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: > > > >> How do you guys handle errors during, say, db insertions. > >> > >> Let's say you have an ongoing transaction which fails on the n-th > >> insert. Ok, you roll back the transaction, no problem. How do you then > >> inform the user? Just using the text from pg_result_error or > >> something? > > > > I use trigger_error() and stop execution at that point. I give the user > > an error that basically says, "Talk to the admin/programmer". And I send > > the programmer a message containing a trace of what occurred. The theory > > is that, all things being equal, such an error should never occur and > > there is no user recovery. If the user properly entered the data they > > were asked for, then the transaction should go through without incident. > > If something prevents the transaction from going through, it's likely a > > coding problem and up to the programmer or admin to repair. > > > > Fair reasoning, but it amounts to throwing a bucket of cold water in > the face of your user. If I was looking at an error like that, I'd get > mighty annoyed with the software, and after a while would definitely > look for alternatives. Whether or not there's a coding problem, you > have to look at the situation from the point of the user: a complete > failure with no information is like a BSOD/TSOD ... and we all know > the effect they have on a user. I assume (1) that I've vetted the user data and given them the option to repair it if it's faulty; (2) beyond the beta phase, this type of error should not happen. If it does, it's a coding problem. Given that the user can do *nothing* about this and it *is* a coding problem, what would you tell the user? If I was the user, I'd be cranky as well. But if I were a smart user, I'd realize that the programmer made a mistake and put the responsibility firmly on him. And expect him to fix it pronto. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 10:46 AM, Peter Lind wrote: > On 27 April 2010 10:42, Gary . wrote: >> How do you guys handle errors during, say, db insertions. >> >> Let's say you have an ongoing transaction which fails on the n-th >> insert. Ok, you roll back the transaction, no problem. How do you then >> inform the user? Just using the text from pg_result_error or >> something? >> > > If it's a normal user, give them some info about what went wrong but > not the specific error returned. Yeah. I know :( Originally I couldn't find a "nice" way of translating between db errors and "user" errors. The only interface to the db errors that I could find was the error messages returned from pg_last_error. Yes, I could have used an array translating between the the strings returned by pg_last_error or whatever, but *gag* it would not only have made the code look horrible but would also have been susceptible to changes in the error messages returned by the db interface. In the end I changed tack slightly and used pg_send_* and pg_result_error_field to get a short code I could use as a reference into an array. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 15:36, Paul M Foster wrote: > On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: > >> How do you guys handle errors during, say, db insertions. >> >> Let's say you have an ongoing transaction which fails on the n-th >> insert. Ok, you roll back the transaction, no problem. How do you then >> inform the user? Just using the text from pg_result_error or >> something? > > I use trigger_error() and stop execution at that point. I give the user > an error that basically says, "Talk to the admin/programmer". And I send > the programmer a message containing a trace of what occurred. The theory > is that, all things being equal, such an error should never occur and > there is no user recovery. If the user properly entered the data they > were asked for, then the transaction should go through without incident. > If something prevents the transaction from going through, it's likely a > coding problem and up to the programmer or admin to repair. > Fair reasoning, but it amounts to throwing a bucket of cold water in the face of your user. If I was looking at an error like that, I'd get mighty annoyed with the software, and after a while would definitely look for alternatives. Whether or not there's a coding problem, you have to look at the situation from the point of the user: a complete failure with no information is like a BSOD/TSOD ... and we all know the effect they have on a user. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote: > How do you guys handle errors during, say, db insertions. > > Let's say you have an ongoing transaction which fails on the n-th > insert. Ok, you roll back the transaction, no problem. How do you then > inform the user? Just using the text from pg_result_error or > something? I use trigger_error() and stop execution at that point. I give the user an error that basically says, "Talk to the admin/programmer". And I send the programmer a message containing a trace of what occurred. The theory is that, all things being equal, such an error should never occur and there is no user recovery. If the user properly entered the data they were asked for, then the transaction should go through without incident. If something prevents the transaction from going through, it's likely a coding problem and up to the programmer or admin to repair. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 10:42, Gary . wrote: > How do you guys handle errors during, say, db insertions. > > Let's say you have an ongoing transaction which fails on the n-th > insert. Ok, you roll back the transaction, no problem. How do you then > inform the user? Just using the text from pg_result_error or > something? > > Developers are usually lazy about error reporting because it's much easier to just return the error code. Some parsing is very useful to the user, since overtly technical information is just confusing. The error should never be something that the user himself can avoid (since you're supposed to have error checking and handling before the user submits), so your error should make this clear to him. It helps to let him know that the developer has been notified and that he can try again later. Michiel
Re: [PHP] Error handling strategies (db related)
On 27 April 2010 10:42, Gary . wrote: > How do you guys handle errors during, say, db insertions. > > Let's say you have an ongoing transaction which fails on the n-th > insert. Ok, you roll back the transaction, no problem. How do you then > inform the user? Just using the text from pg_result_error or > something? > If it's a normal user, give them some info about what went wrong but not the specific error returned. If it's an admin with dev knowledge (i.e. you) then consider handing out the returned error as well. Rule of thumb: aim to inform the user without confusing. There's nothing worse than "This didn't work, sorry" - why didn't it work?? Was it my fault? Can I get it to work somehow? Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Error handling strategies (db related)
How do you guys handle errors during, say, db insertions. Let's say you have an ongoing transaction which fails on the n-th insert. Ok, you roll back the transaction, no problem. How do you then inform the user? Just using the text from pg_result_error or something? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
