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 7:34 PM, Gary . php-gene...@garydjones.name 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 April 2010 10:42, Gary . php-gene...@garydjones.name 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 -- hype 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 /hype -- 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 . php-gene...@garydjones.name 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 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 15:36, Paul M Foster pa...@quillandmouse.com 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 -- hype 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 /hype -- 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 Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: On 27 April 2010 15:36, Paul M Foster pa...@quillandmouse.com 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 27 April 2010 16:07, Paul M Foster pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: On 27 April 2010 15:36, Paul M Foster pa...@quillandmouse.com 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 -- hype 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 /hype -- 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 pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: On 27 April 2010 15:36, Paul M Foster pa...@quillandmouse.com 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:24, Paul M Foster pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: On 27 April 2010 16:07, Paul M Foster pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: On 27 April 2010 15:36, Paul M Foster pa...@quillandmouse.com 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 -- hype 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 /hype -- 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 pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: On 27 April 2010 16:07, Paul M Foster pa...@quillandmouse.com wrote: On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: On 27 April 2010 15:36, Paul M Foster pa...@quillandmouse.com 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)
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)
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 . 'br /' .$line . 'br /' . $file . 'br /' .
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)
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 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)
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)
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 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)
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: ?php ? 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)
On 27 April 2010 18:21, tedd tedd.sperl...@gmail.com 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 -- hype 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 /hype -- 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 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 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)
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 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: ?php ? 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)
On Tue, Apr 27, 2010 at 12:23 PM, tedd tedd.sperl...@gmail.com 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: ?php ? 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: br / bWarning/b: Deadbeat script. Your code does not do anything useful in bteddscript.php/b on line b1/bbr / :-) Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling (skip this message my mistake)
Sorry,
i found the error. it was my mistake
- Original Message
From: It Maq [EMAIL PROTECTED]
To: php-general@lists.php.net
Sent: Tuesday, March 11, 2008 11:38:10 AM
Subject: [PHP] Error handling
Hi,
I need help with a simple script that i made for handling errors. The problem
is that the script displays the same message several times while i want it
displayed just one time.
He is the code:
?php
function error_handler($errno, $errstr, $filename, $lineno, $context)
{
if ($errno == E_STRICT) {
echo you are in the function error_handlerbr;
echo $errno. br;
}
}
set_error_handler(error_handler, E_STRICT);
ini_set('error_reporting', 0);
$conn = mysql_connect(localhost, root, iolfsyd) or trigger_error(connection au
serveur failed,WARNING);
?
Thanks
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [PHP] Error Handling question
On Mon, August 6, 2007 4:41 am, debussy007 wrote:
I am new to PHP and need some help for error handling.
I read in the docs that i can handle the errors this way in my PhP:
set_error_handler('errorHandler');
function errorHandler($errnum,$errmsg,$file,$lineno){
[...]
}
But does that mean that I have to copy paste this code in all my Php
pages
or is there a better way ?
Put it in an include file with all the other functions you are going
to need shortly.
http://php.net/include
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling question
debussy007 wrote:
Hi,
I am new to PHP and need some help for error handling.
I read in the docs that i can handle the errors this way in my PhP:
set_error_handler('errorHandler');
function errorHandler($errnum,$errmsg,$file,$lineno){
[...]
}
But does that mean that I have to copy paste this code in all my Php pages
or is there a better way ?
You could use auto_prepend_file:
http://www.php.net/manual/en/ini.core.php#ini.auto-prepend-file
brian
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling
E_USER_WARNING is a 'constant' whose value is a number.
It is not a string.
If you do this:
echo E_USER_WARNING is set to ', E_USER_WARNING, 'br /\n;
you will see exactly what number it is.
So whatever you thought was going wrong, this is not it.
In addition...
The check for $query should probably be more like if (strlen($query))
since it's remotely possible that you could screw up badly enough for
$query to start with characters which happen to fall in the range of
0-9, and if that happens to be, say:
0 and user_id = other_table.user_id
then this test will fail, despite having a borked $query as the root
cause of your troubles.
I've got no idea what that mess of stuff about the errcontext is all
about, but I suspect that unless you are ALSO using their same
object-oriented error handling modules, and have included the source
for that, then your error handler is probably puking on itself, and
PHP is probably refusing to do infinite recursion to call the error
handler from within the error handler. Or it *IS* doing exactly that,
and spiking your CPU before it chokes on the time limit (or even
memory limit) in php.ini
If that's not the problem, then I don't see anything here, other than
some icky code style, that is wrong.
On Thu, March 1, 2007 3:24 pm, Chris Ditty wrote:
I am trying to add some error handling to my code. Instead of
reinventing the wheel, I searched and found the code below. For the
most part, it seems to work. When I have an error, it doesn't get
shown. However, I don't get any output. I tracked it down to the
$errno. It is outputting a number where the switch statement is
expecting words. Short of typing an array converting number to
words, what am I missing/doing wrong?
set_error_handler('errorHandler');
function errorHandler ($errno, $errstr, $errfile, $errline,
$errcontext){
global $query;
switch ($errno){
case E_USER_WARNING:
case E_USER_NOTICE:
case E_WARNING:
case E_NOTICE:
case E_CORE_WARNING:
case E_COMPILE_WARNING:
break;
case E_USER_ERROR:
case E_ERROR:
case E_PARSE:
case E_CORE_ERROR:
case E_COMPILE_ERROR:
if(eregi('^(sql)$', $errstr)){
$MYSQL_ERRNO = mysql_errno();
$MYSQL_ERROR = mysql_error();
$errstr = MySQL error: $MYSQL_ERRNO : $MYSQL_ERROR;
}else{
$query = NULL;
}
$errorstring = h2 .date('Y-m-d H:i:s') ./h2\n;
$errorstring .= pFatal Error: $errstr (# $errno)./p\n;
if ($query) $errorstring .= pSQL query: $query/p\n;
$errorstring .= pError in line $errline of file
'$errfile'./p\n;
$errorstring .= pScript: '{$_SERVER['PHP_SELF']}'./p\n;
if(isset($errcontext['this'])){
if(is_object($errcontext['this'])){
$classname = get_class($errcontext['this']);
$parentclass =
get_parent_class($errcontext['this']);
$errorstring .= pObject/Class: '$classname',
Parent Class:
'$parentclass'./p\n;
}
}
echo h2This system is temporarily unavailable/h2\n;
echo pThe following has been reported to the
administrator:/p\n;
echo bfont color='red'\n$errorstring\n/b/font;
/*error_log($errorstring, 1, $_SERVER['SERVER_ADMIN']);
$logfile = $_SERVER['DOCUMENT_ROOT'] .'/errorlog.html';
error_log($errorstring, 3, $logfile);*/
/*session_start();
session_unset();
session_destroy();*/
die();
default:
break;
}
# prevent further script execution
exit();
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling for Memcached PHP Extension
Didja see this one: http://us3.php.net/manual/en/function.memcache-debug.php Not, perhaps, the best answer, and maybe even not possible in your environment, but it may be useful for development, if not production. You could also check the getServerStats functions to see if their stats provide any indication that the server is up/down. And finally, I suspect that you could submit a patch to get a memcache_error() function without TOO much effort... On Sun, February 25, 2007 5:35 pm, Cabbar Duzayak wrote: Hi, Before I start, I am not sure whether I should have sent this to Memcached or PHP mailing list. So, for those who are subscribed to both, I apologize. I have started using the PHP extension at http://pecl.php.net/package/memcache for memcached. But, one problem I am having right now is that, php functions tells you nothing about errors. For example, when you call Memcache::get, it returns true or false, but when it returns false does this mean item is not found, or Memcached is down, or there is a cache corruption / compression error, etc. etc. And, this also is the case for Memcache::set, again when it returns false, you have no idea about what is going on. I tried turning debugging on, and this did not help much. As far as I can see, memcache internally sets error nos, but this extension completely ignores this information. And, I saw something like: PHP Notice: Memcache::get(): marked server 'localhost:11211' as failed in my php logs for some of the requests (like 5-10 out of a thousand), but server was up, and everthing was normal, and the request right after this one succeeded. In summary, is it possible to get these errors from PHP somehow so that we can have an idea about what is going on and how we can handle them? Possibly with something like mysql_error or mysql_errno functions? Thanks in advance... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling Library?
Hi!, u can extend the exception class and handle ur own errors, If u need help let me know! Rafa On 8/31/06, Jay Paulson [EMAIL PROTECTED] wrote: I've been doing some research and was wondering if anyone out there has written a library for error handling? I haven't found anything as of yet but would love to hear suggestions! Thanks! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling Library?
On Thu, 2006-08-31 at 11:12 -0500, Jay Paulson wrote: I've been doing some research and was wondering if anyone out there has written a library for error handling? I haven't found anything as of yet but would love to hear suggestions! PEAR Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling Library?
I'm curious, what features are you looking for in an error handling library? 2006/8/31, Jay Paulson [EMAIL PROTECTED]: I've been doing some research and was wondering if anyone out there has written a library for error handling? I haven't found anything as of yet but would love to hear suggestions! Thanks! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] error handling
On Wednesday 13 April 2005 08:46, Cima wrote: hi, im working with php 4 and postgresql 8 and i would like to know how to handle certain errors generated. in postgresql, i've written a stored function that selects a record from a table and in case no record is found i 'raise an exception'. fine, now in my php script i call that the stored function which works properly when there is a record but when the record doesnt exist, i would like to be able to place my own error message and not e.g 'fatal error, .'. how do i capture(in php) the exception i raised in postgres so that i know the record doesnt exist? Possible scenarios are: 1. Use string parsing to recognise the error message. 2. Upgrade to PHP 5, which is not that good if you need to change a lot of code afterwards. thanx. -- Cyberly yours, Petar Nedyalkov Devoted Orbitel Fan :-) PGP ID: 7AE45436 PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436 pgpOwxvUjhcjw.pgp Description: PGP signature
RE: [PHP] error handling
Personally, I create a custom error handler for all my apps (currently 4.3.*
compliant). While I normally use Smarty and have separate error templates,
here is a quick example.
function errorHandler($errno, $errstr, $errfile, $errline )
{
print Error #: $errno br/Error Message: $error_Message;
}
set_error_handler(errorHandler);
call_some_pgsql_function();
-Original Message-
From: Cima [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 12, 2005 11:46 PM
To: php
Subject: [PHP] error handling
hi,
im working with php 4 and postgresql 8 and i would like to know how to
handle certain errors generated. in postgresql, i've written a stored
function that selects a record from a table and in case no record is found i
'raise an exception'. fine, now in my php script i call that the stored
function which works properly when there is a record but when the record
doesnt exist, i would like to be able to place my own error message and not
e.g 'fatal error, .'. how do i capture(in php) the exception i raised
in postgres so that i know the record doesnt exist?
thanx.
--
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
[snip] I have found some great code that handles errors through PHP_SELF However I have radio buttons and drop down selections that I cannot do a $_POST (the POST only works on my text fields). Does someone have some sample code that can check for errors on a drop down selection or radio buttons and then post the selection back to the form if the form is not complet? [/snip] The post should work on any submitted field. print_r($_POST) and you should see all of the name/value pairs in the array, including drop downs and radio buttons where nothing was selected. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
On Fri, 2003-10-17 at 16:29, Frank Tudor wrote: I have found some great code that handles errors through PHP_SELF However I have radio buttons and drop down selections that I cannot do a $_POST (the POST only works on my text fields). Does someone have some sample code that can check for errors on a drop down selection or radio buttons and then post the selection back to the form if the form is not complet? Error Handling?? Do you mean form validation? InterJinn does form validation and allows custom validators for any kind of form field. I believe PEAR's Quickform can also do similar. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
Robert Cummings wrote: Error Handling?? Do you mean form validation? InterJinn does form validation and allows custom validators for any kind of form field. I believe PEAR's Quickform can also do similar. I'm thinking about getting a vasectomy; what does InterJinn recommend? Seriously, is it just me or have you been recommending InterJinn for the solution to every problem today or what?? -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
On Fri, 2003-10-17 at 18:49, John W. Holmes wrote: Robert Cummings wrote: Error Handling?? Do you mean form validation? InterJinn does form validation and allows custom validators for any kind of form field. I believe PEAR's Quickform can also do similar. I'm thinking about getting a vasectomy; what does InterJinn recommend? InterJinn recommends you configure the pain handler, possibly override it for complete relief of pain. Optionally after the procedure you should clear your session. Seriously, is it just me or have you been recommending InterJinn for the solution to every problem today or what?? I recommended it twice... if the shoe fits... and hey, I'm most familiar with what I wrote :) Incidentally I make comment to Quickform above also, since its the only popular form system I know of, though I don't use it since IMHO mine is better *grin*. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
John W. Holmes wrote: Robert Cummings wrote: Error Handling?? Do you mean form validation? InterJinn does form validation and allows custom validators for any kind of form field. I believe PEAR's Quickform can also do similar. I'm thinking about getting a vasectomy; what does InterJinn recommend? Seriously, is it just me or have you been recommending InterJinn for the solution to every problem today or what?? I had InterJinn Simonize my car this morning. :) -- By-Tor.com It's all about the Rush http://www.by-tor.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
On Fri, 2003-10-17 at 23:14, John Nichel wrote: I had InterJinn Simonize my car this morning. :) Hmm, that's an odd word to use... I hope your car enjoyed its simonizing. But don't let it get carried away :) Cheers, Rob -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
Interjinn looks great but my development box is a windows me machine with easyphp (globals turned off) How am I supposes to get this stuff to work. I actually just unzipped it to my www dir and it has been sitting there the whole day. and I still have my vailidation (form handling) problem. I would really be interested in quickforms or interjinn or something easy that can get this form under control. Any other suggestions? Besides a brain transplant... :) Frank --- Robert Cummings [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 23:14, John Nichel wrote: I had InterJinn Simonize my car this morning. :) Hmm, that's an odd word to use... I hope your car enjoyed its simonizing. But don't let it get carried away :) Cheers, Rob -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
Frank, http://pear.php.net/HTML_QuickForm It's that easy. There are full docs accessible from the page listed above. Average time from download to output of your first form with validation: 30 minutes to 1 hour. Tops. Regards, Greg Frank Tudor wrote: I would really be interested in quickforms or interjinn or something easy that can get this form under control. Any other suggestions? Besides a brain transplant... You might consider gingko biloba... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling
On Sat, 2003-10-18 at 00:07, Frank Tudor wrote: Interjinn looks great but my development box is a windows me machine with easyphp (globals turned off) How am I supposes to get this stuff to work. I actually just unzipped it to my www dir and it has been sitting there the whole day. and I still have my vailidation (form handling) problem. I would really be interested in quickforms or interjinn or something easy that can get this form under control. Send me an email offlist of what you want the form to do, and I'll explain how to set the configuration and to implement the form so that you only use the formJinn feature. The installation and configuration documentation should be good source of info too, though admittedly heavy for a novice. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] error handling
On Friday 20 June 2003 02:11, Mignon Hunter wrote: On my dev server the php.ini is set to log all errors and notices. Isnt there a way to over ride this on a per script basis to output to stdout (or my browser) ? Yes, manual Error Handling and Logging Functions -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* Most people's favorite way to end a game is by winning. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling with multiple file uploads and sql
Why not split it into 2 forms? insert, then attach pictures to the record. Otherwise, decide what's the key issue (imho the a record can exist without pics, but not vice-versa), and focus on that first. Justin on 06/01/03 10:15 PM, Jim ([EMAIL PROTECTED]) wrote: Hi, I have the following scenario: A user can login to my website (so I know their ID) and create a new 'item record' through a form. This item may have up to 10 images uploaded with it (pictures of the item). The structure of my DB is a main 'Items' table holding textual description/price/location information of the item and another table 'Pictures' holding information on each image uploaded. My problem is how to handle an error if something goes wrong i.e. sql insert fails or the file copy() fails. What I don't want to happen is for the 'Items' record to be created and then 1 or more files fail to upload. So I thought, I'll upload the files first, but the problem with this is that in the 'Pictures' table I have to enter an 'ItemID' field obviously to link the pictures to the item, but the ID of the item isn't known as it hasn't been created yet. Ahh!! My next thought was to upload the files first, then insert the 'Items' record, then insert the multiple 'Pictures' records.I figure if the 'Items' insert works, the likelihood is that the 'Pictures' inserts will too. How does this sound? Thanks for any input. Jim. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling with multiple file uploads and sql
Why not split it into 2 forms? insert, then attach pictures to the record. Its just not user-friendly enough, I have thought about it though. I think I'd rather risk the script hitting an error than compromise the user-friendliness.after all, the chance of a file not saving is miniscule as I can guarantee no other file will exist with that nameand for the sql to fail would probably mean the DB server being offline which would mean the user would never even get to the form in the first place. Otherwise, decide what's the key issue (imho the a record can exist without pics, but not vice-versa), and focus on that first. I see where your coming from but it can happen vice-versa. I assign the image a name in the format pic?= $userid ?_?= $usercount ?.gif so if the users id is 12 and that user already has 12 images, the filename would be pic12_13.gif. These names are then stored in the 'Pictures' table. This is how the logic might go (assuming user id 12): 1. SELECT CurrentPictureNum FROM Users WHERE UserID = 12 -- CountPictureNum never gets decremented 2. loop $_FILES and count number of images (don't save yet) 3. UPDATE Users SET CountPictures = CountPictures + ?= $number_of_new_images ? -- this guarantees no files in the future will overwrite -- the ones which are about to be saved 4. loop $_FILES again but this time save them 5. INSERT INTO Items VALUES (..) -- if it fails here, who cares, it just means images are -- stored which don't need to exist, i can write a cleanup -- script to deal with these though 6. loop over array of names of new images and INSERT INTO Pictures VALUES () -- this is the only dodgy bit, if we fail here the Items -- record has been created but the script fails. I think -- however its fair to assume though that if the first -- insert worked, these will too. Opinions? Thanks, Jim. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] error handling
Try this. In your php.ini file:
display_errors = Off
log_errors = On
track_errors = On
Then in your code:
$php_errormsg = false;
ob_start();
... your code ...
if($php_errormsg) {
ob_end_clean(); // Error - discard buffer
echo An error occurred - webmaster notified;
} else {
ob_end_flush(); // No error, send buffer
}
-Rasmus
On Sun, 17 Nov 2002, Mattia wrote:
When the display_errors is Off, and the output of the page comes all in the
end, or when you're using some template engine or some output buffer
function (ob_start()), no output is displayed to the screen! I would like to
tell a message to the use in case of failure of the scripy, without giving
the information of the kind of error it is.
Display a message like: the application has caused an error! the webmaster
has been notified by email.
And the precise error in the error log, like: Parse error in line file
Is there anythig to do it without setting up a custom error log?
thanks
Mattia
--
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 Class - Any Recommendations?
On Thursday, April 18, 2002, at 08:53 AM, Julio Nobrega Trabalhando wrote: Anyone recommend a good one? I am in need of the following features: 1) Catch any type of errors, 2) Actions like: Show on the screen, log on a file or database, or email, 3) Different actions for each error level/warning type, etc.. If you want to roll your own, there's a DevShed article on the subject -- but I haven't read it, so I can't give you an opinion as to how good it is (whatever that would be worth). http://www.devshed.com/Server_Side/PHP/FormValidatorClass/page1.html Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling!
On Tue, 12 Mar 2002, Thomas Edison Jr. wrote:
I want errors reported on a page when the mail()
function for any reason fails to send emails. FOr
example, if there is a malformed email address or
anything, and the mail is not sent, how can i catch
the Error and Display it on the page?
the easiest way is:
?
error_reporting(0); // you're the one who want's to report errors, not php
function mailerror() {
print Something went wrong.;
// etc...
}
mail(...) || mailerror();
?
Thanks,
T. Edison Jr.
=
Rahul S. Johari (Director)
**
Abraxas Technologies Inc.
Homepage : http://www.abraxastech.com
Email : [EMAIL PROTECTED]
Tel : 91-4546512/4522124
***
__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
--
Jan Rademaker [EMAIL PROTECTED]
http://www.ottobak.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error Handling!
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... I want errors reported on a page when the mail() function for any reason fails to send emails. FOr example, if there is a malformed email address or anything, and the mail is not sent, how can i catch the Error and Display it on the page? Thanks, T. Edison Jr. I don't think that is really posible. The mail() function doesn't actually send the mail; all it does is hands it off to the defined MTA which looks after the sending etc. There have been numerous discussions on the list about how to check a mail address - have a look over those and see if there is something suitable for checking the address before processing it with mail(). Also, I recall there is a header item something like Errors to: in which you can define an address which will receieve error messages from the MTA; you'll need to check the RFCs for the correct definition. -- David Robley Temporary Kiwi! Quod subigo farinam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Error handling
What warnings are you receiving? Many can be avoided by doing various checks: e.g. if (!isset($some_variable)) ...some error code else ...all is well others which may be useful: function_exists() file_exists() HTH Neil Yoel Benitez Fonseca wrote: Hi! There is in PHP some way to handle errors like in other languages, I mean, something like this: . . . try to do ... if error then do ... . . . I'm tired of reciving warnings :-( -- Yoel Benitez Fonseca -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] *** This message was virus checked with: SAVI 3.52 last updated 17th December 2001 *** -- Email: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [PHP] error handling and __LINE__
Thanks, assert() is cool, but it still reports the filename and line
number of the included file with the function in which the error
occurred, not the script that called the functon with illegal arguments.
Or...???
Eg.:
index.php:
?
include_once(functions.php);
// foo() is declared here
foo(123);
// illegal argument
?
This will produce a message saying an error occurred in functions.php,
but I want it to tell me that the error occurred in index.php, line 3.
Because if I call foo() many times in a script, it is difficult to find
out which call that failed.
Is this impossible?
Papp Gyozo wrote:
try, assert() instead of echo()ing error messages.
assert('is_object($obj)');
and write your error handler code or use mine :)
or am i missing something?
Papp Gyozo
- [EMAIL PROTECTED]
- Original Message -
From: SafeV [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 22, 2001 4:15 PM
Subject: [PHP] error handling and __LINE__
| Hi,
| I wonder if there's a way to find the line number of the calling script
| from a function, like the error messages PHP generates. An example:
|
| In an included file I have a function and want to do something similar to:
|
| function foo($obj) {
| if (!is_object($obj)) {
| echo Error: supplied argument is not an object in ;
| echo __FILE__ . line . __LINE__;
| }
| ...
| }
|
| But __FILE__ and __LINE__ refers to the current file, ie. the file with
| the function in, and not the file where the function is called from.
| The first one I can solve by using $SCRIPT_NAME, but what about the line
| number???
|
|
|
| --
| PHP General Mailing List (http://www.php.net/)
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
| To contact the list administrators, e-mail: [EMAIL PROTECTED]
|
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] error handling and __LINE__
try, assert() instead of echo()ing error messages.
assert('is_object($obj)');
and write your error handler code or use mine :)
or am i missing something?
Papp Gyozo
- [EMAIL PROTECTED]
- Original Message -
From: SafeV [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 22, 2001 4:15 PM
Subject: [PHP] error handling and __LINE__
| Hi,
| I wonder if there's a way to find the line number of the calling script
| from a function, like the error messages PHP generates. An example:
|
| In an included file I have a function and want to do something similar to:
|
| function foo($obj) {
| if (!is_object($obj)) {
| echo Error: supplied argument is not an object in ;
| echo __FILE__ . line . __LINE__;
| }
| ...
| }
|
| But __FILE__ and __LINE__ refers to the current file, ie. the file with
| the function in, and not the file where the function is called from.
| The first one I can solve by using $SCRIPT_NAME, but what about the line
| number???
|
|
|
| --
| PHP General Mailing List (http://www.php.net/)
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
| To contact the list administrators, e-mail: [EMAIL PROTECTED]
|
RE: [PHP] Error Handling class
the PEAR library has an error class -Stewart. -Original Message- From: Boget, Chris [mailto:[EMAIL PROTECTED]] Sent: 12 April 2001 16:19 To: Php (E-mail) Subject: [PHP] Error Handling class I've looked around but haven't really found one... Does anyone know where I can find a class (or a set of functions) that handles errors gracefully? I'm about to write something to do this but would rather not reinvent the wheel. thnx, Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] error handling
On Thu, 15 Feb 2001 11:42, Patrick Brown wrote: How can I disable the display of error to the browser window from within the script? I want to do a redirect based on the error and cannot because header info has already been sent. Thanks, Pat Try an @ prepended to the function that triggers the error, then test for the error. @ should prevent the display of the error message. -- David Robley| WEBMASTER Mail List Admin RESEARCH CENTRE FOR INJURY STUDIES | http://www.nisu.flinders.edu.au/ AusEinet| http://auseinet.flinders.edu.au/ Flinders University, ADELAIDE, SOUTH AUSTRALIA -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] error handling
In article 96faad$h9k$[EMAIL PROTECTED], [EMAIL PROTECTED] ("Patrick
Brown") wrote:
How can I disable the display of error to the browser window from within the
script? I want to do a redirect based on the error and cannot because header
info has already been sent.
Use the "@" sign. Example
@some_function()
--
CC
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] error handling
OK, I tried the @ symbol. It seemed to just disable error checking
altogether. I have this in my code that I'd like to use.
if (!$php_errormsg) {
header("Location: http://www.domain.com/admin/index.php");
}
else {
header("Location: http://www.domain.com/admin/error.html");
}
"CC Zona" [EMAIL PROTECTED] wrote in message
96fcv5$2o0$[EMAIL PROTECTED]">news:96fcv5$2o0$[EMAIL PROTECTED]...
In article 96faad$h9k$[EMAIL PROTECTED], [EMAIL PROTECTED] ("Patrick
Brown") wrote:
How can I disable the display of error to the browser window from within
the
script? I want to do a redirect based on the error and cannot because
header
info has already been sent.
Use the "@" sign. Example
@some_function()
--
CC
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
