1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<sect1 xml:id="language.errors.basics" xmlns="http://docbook.org/ns/docbook">
<title>Basics</title>
<para>
PHP reports errors in response to a number of internal error conditions.
These may be used to signal a number of different conditions, and can be
displayed and/or logged as required.
</para>
<para>
Every error that PHP generates includes a type. A
<link linkend="errorfunc.constants">list of these error types</link> is available,
along with a short description of their behaviour and how they can be
caused.
</para>
<sect2 xml:id="language.errors.basics.handling">
<title>Handling errors with PHP</title>
<para>
If no error handler is set, then PHP will handle any errors that occur
according to its configuration. Which errors are reported and which are
ignored is controlled by the
<link linkend="ini.error-reporting"><parameter>error_reporting</parameter></link>
php.ini directive, or at runtime by calling
<function>error_reporting</function>. It is strongly recommended that the
configuration directive be set, however, as some errors can occur before
execution of your script begins.
</para>
<para>
In a development environment, you should always set
<link linkend="ini.error-reporting"><parameter>error_reporting</parameter></link>
to <constant>E_ALL</constant>, as you need to be aware of and fix the
issues raised by PHP. In production, you may wish to set this to a less
verbose level such as
<code>E_ALL & ~E_NOTICE & ~E_DEPRECATED</code>, but
in many cases <constant>E_ALL</constant> is also appropriate, as it may
provide early warning of potential issues.
</para>
<para>
What PHP does with these errors depends on two further php.ini directives.
<link linkend="ini.display-errors"><parameter>display_errors</parameter></link>
controls whether the error is shown as part of the script's output. This
should always be disabled in a production environment, as it can include
confidential information such as database passwords, but is often useful to
enable in development, as it ensures immediate reporting of issues.
</para>
<para>
In addition to displaying errors, PHP can log errors when the
<link linkend="ini.log-errors"><parameter>log_errors</parameter></link>
directive is enabled. This will log any errors to the file or syslog
defined by
<link linkend="ini.error-log"><parameter>error_log</parameter></link>. This
can be extremely useful in a production environment, as you can log errors
that occur and then generate reports based on those errors.
</para>
</sect2>
<sect2 xml:id="language.errors.basics.user">
<title>User error handlers</title>
<para>
If PHP's default error handling is inadequate, you can also handle many
types of error with your own custom error handler by installing it with
<function>set_error_handler</function>. While some error types cannot be
handled this way, those that can be handled can then be handled in the way
that your script sees fit: for example, this can be used to show a custom
error page to the user and then report more directly than via a log, such
as by sending an e-mail.
</para>
</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
|
