hide error messages

hiding automatic error messages in php

[WhosAWhata]

I have a script that works perfectly and does everything I want it to do, except that occassionally it gives an error message at the top of the output

like Warning: stristr(): Empty delimiter. in /this/addresss/script.php on line 58

I don't know why it does this, and frankly I don't care, because like i said it works just how i want it to. is there a way to make php hide those error messages?

[NickCoons]

I think you can prepend functions with an @ sign and it will supress errors. I've not tried it myself.. I prefer catching the error and preventing it. In your case, an if() before the stristr() function may be a good idea to make sure that the delimiter is not empty before trying to execute stristr().

[WhosAWhata]

thanks, but the thing is, that is only one of the many error mesages that appears, and i actually don't even have that function on that line. is there any way to hide every error that appears?

[NickCoons]

error_reporting(0) should do it for you, but this will obviously make it difficult to troubleshoot other issues.

If errors are occuring and you don't know why, it's not good practice to just ignore them, because they could easily manifest themselves in other ways.. like data corruption, performance hits, etc. I would highly recommend finding out why you're getting errors in your script even though it *appears* to be working properly at the moment.

[ergophobe]

On my test server, I recently changed to the highest level of error reporting. At first it was a pain, but it makes your code more secure by flagging undefined variables and all sorts of things like that.

I think it's best to code with error reporting high and run with it low (or logged, but in any case not shown to end users and malicious people looking for exploits)

Tom

[coopster]

Excellent advice, NickCoons and ergophobe. One minor correction; replace the word functions with expressions:

>>I think you can prepend functions with an @ sign and it will supress errors.

Actually, and the PHP Manual [php.net] states it best:

Note: The @-operator works only on expressions [php.net]. A simple rule of thumb is: if you can take the value of something, you can prepend the @ operator to it. For instance, you can prepend it to variables, function and include() calls, constants, and so forth. You cannot prepend it to function or class definitions, or conditional structures such as

if

and

foreach

, and so forth.

An often overlooked task of programmers is proper error monitoring and control. It can be tedious at times but do yourself a favor and get into a good habit early. Your code will be much more secure and display what you want it to, not what it thinks it should when errors are encountered.

[louponne]

hm, I think this is a perfect place to ask my own question.

I have "normal" error reporting on my coding machine, and do extensive testing to eliminate all errors I find.

But one thing keeps bothering me. I do my scripting of queries and such directly, thusly:

$sql="SELECT var1,var2,var3
FROM table1
WHERE var1='$thing'";
$result=mysql_query($sql)or die(mysql_error());
while ($info = mysql_fetch_array($result,MYSQL_ASSOC)){
etc...

I keep reading in php books examples where they check first for the mysql connection not working, then the query not working, then.... etc. (and sending an error message to the browser if they hit a problem).

I've never seen a problem on a site I've coded with a connection not working or a query not working. Is it really important to do it the way the manuals say?

[NickCoons]

This might be good for testing purposes, but I don't think it's a good idea to send the results of mysql_error() to the user's browser. Others may disagree.

It may be a good idea to use die() with custom text in functions that have a real potential to fail. The custom text is enough to tell you what's wrong, but not enough to let a potential hacker know about any exploits.

Opening a MySQL database connection may fail if the connection is made to a remote machine over the internet (high network traffic could cause connection problems), or the service may fail even if it's running on the local machine. I haven't seen this call fail before, so I don't know what the error looks like.. but you don't want error messages displaying to the user that reveal file paths, usernames, or passwords on your system.

[ergophobe]

I don't think it's a good idea to send the results of mysql_error() to the user's browser. Others may disagree..... you don't want error messages displaying to the user that reveal file paths, usernames, or passwords on your system.

I completely agree, both for usability and security reasons. Ideally you should have a high level of error reporting for testing, and then errors should be handled as gracefully as possible on a public site. I think the only way you can achieve this is by testing (at appropriate moments) that connections are open, queries are successful and variables are set and then appropriate handlers set (i.e. redirects to a simple page that has the same template but says "I'm sorry, there was a problem making a connection to the database. Please try again. If the problem persists, please contact the site adminstrator at [e-mail]"). I'm not saying *I* do this scrupulously, but if it's important, I try to.

I've seen some open source packages (osCommerce?) that build in a debug flag so you can set a constant called DEBUG to TRUE or FALSE. Then you can say

if connection is open, do stuff
if connection failed and DEBUG, send detailed message to the browser
if connection failed and!DEBUG, send user to a friendly error page.

and then add all sorts of debug stuff in their footer. That seems like unnecessary complexity and overhead for most of the stuff I do, but I suppose it could save a lot of headaches tracking things down.

Tom