Programming errors:
- Syntax: Errors with php rules will show up in the php parser, which won't be able to process that part of the script. Most common are failures to end statements with semicolons, strings without closing quotation marks, parameters passed to functions without comma separators or surrounding parentheses.
- Runtime: Scripts that look for non-existent objects (include files, database tables) or that have major logic flaws (division by zero, infinite loops), will trigger an error message. Other runtime errors come from faulty interactions with MySQL or other databases, connections to network services, or a failure due to faulty input data.
- Non-existent functions: These may be php function names that are spelled incorrectly (or that use or fail to use underscores, etc.), or that call for a different number of parameters than what you have provided.
- Reading or Writing Files: Calls to read or write files have a return boolean to indicate success or failure. Make certain that there is code to handle failure.
- MySQL: You can fail to connect to a database if you specify the wrong server, database, or table, or if the server is malfunctioning or down, for example. Again, check the boolen return value, as we have been doing in all of our code examples so far. If you are not connected and attempt to continue, the script will generate error messages. Tsk-tsk! Remember, too, that a sucessful connection and query can still produce no results, depending on the SQL WHERE conditions.
- Network services: Again, have a fail-safe response to deal with failure to connect to any network service, in event the internet is down or a service is otherwise not available when you ask for it.
- Input data: Users may enter the unexpected. A common one is the entering of words with single quotes, which are then used in search strings, something you can protect against by using addslashes() (p. 530). Also check for missing entries, etc.
- Logic: Here, the code is doing exactly what it was coded to do, but the coding doesn't work as you intended. Your program logic is flawed. Usually, output is strange, which clues you to look for a reason in the program logic. You have to test with odd input to uncover these flaws, as suggested in the previous chapter.
Dumping variables as a debugging aid: Listing 25.1 (p. 531-2) will dump the contents of the POST, GET, SESSION, and COOKIES arrays, allowing you to check form and state variables.
Error Reporting Settings in PHP: The level of error reporting is det by default in php.ini (see p. 524). For our class, we've set it to include some low level (minor) errors, which may cause an occasional pain but which encourages tighter code as we learn. That is, we 1)report all errors except notices, 2)output error messages as html, 3) log no messages to the server disk, and 4) track no errors. The level of reporting is set by using constants, listed in table 25.1; these can be combined, as shown on p. 534. For example, the constant E_ERROR reports fatal errors at runtime, E_WARNING reports nonfatal errors at runtime, and E_PARSE reports parse errors.
You can turn the error reporting off, so that they don't show on the html of a production site, and turn the logging on, so that you can look at the log for errors without affecting the html stream. Change these using error_reporting(), which is passed one of the error reporting constants listed in table 25.1, temporarily altering the default error reporting setting.
Graceful error handling: One way to deal with errors is to set up exception handlers, which is covered in chapter 7. Listing 25.2 provides a way to customize error messages using the error number returned by php by referring the error constant to your own error handling function, called by set_error_handler('my_own_handler'); This function must have the syntax my_error_handler (int error_type, string error_msg [, string errfile [, int errline [, array errcontext]]])).