Error Trapping Within Classes

[47computers]

Pretty new to PHP, I recently started learning about error trapping.
As of right now, I include the following into a page in my website:

-------BEGIN PASTE--------
error_reporting(E_ERROR | E_PARSE);
set_error_handler("SendErrorReport");

function SendErrorReport($errorNumber, $errorMessage, $errorFile,
$errorLine, $vars)
{
[code for handling the error, reporting it to the admin, etc.]
}
---------END PASTE---------

This is working great and catching everything I'd want to catch on the
page. However, it's not catching any errors that happen within a
class.

For example, the page that has this code also creates an instance of a
given class. It then calls a function on that class. Within that
function in the class's code, I would mess up a line to test the error
trapping, and it is not trapped with the above code, but instead by the
default error handling.

How should I go about also trapping the errors that occur within the
class? Any advice would be much appreciated, thank you.
-David

[ZeldorBlat]

47*********@gmail.com wrote:

Pretty new to PHP, I recently started learning about error trapping.
As of right now, I include the following into a page in my website:

-------BEGIN PASTE--------
error_reporting(E_ERROR | E_PARSE);
set_error_handler("SendErrorReport");

function SendErrorReport($errorNumber, $errorMessage, $errorFile,
$errorLine, $vars)
{
[code for handling the error, reporting it to the admin, etc.]
}
---------END PASTE---------

This is working great and catching everything I'd want to catch on the
page. However, it's not catching any errors that happen within a
class.

For example, the page that has this code also creates an instance of a
given class. It then calls a function on that class. Within that
function in the class's code, I would mess up a line to test the error
trapping, and it is not trapped with the above code, but instead by the
default error handling.

How should I go about also trapping the errors that occur within the
class? Any advice would be much appreciated, thank you.
-David

What do you mean by "mess up a line" ? Change it to include invalid
syntax? From the PHP manual on set_error_handler() :

<snip>
The following error types cannot be handled with a user defined
function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING,
E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the
file where set_error_handler() is called.
</snip>

[47computers]

What do you mean by "mess up a line" ? Change it to include invalid

syntax?

Ah, I see what you mean. When I "messed up a line" what I tried was a
typo to a function call (on a result set from a mysqli->query call, I'd
normally call fetch_assoc, but instead tried fletch_assoc, just to see
how it would break). It looks like that was outside the scope of the
custom error trapping capabilities.

When I, instead, just change the name of a variable being used, then it
traps a simple "undefined variable" error just fine.

Well, I guess as long as some errors are untrappable, that's fine. On
that note, does my trapping at least give me the full available scope?
(error_reporting(E_ERROR | E_PARSE);)

Also, for the errors outside of the custom error trapping scope (such
as parser errors), the default response from the user's perspective is
to just see a blank page. Is there any way to change that? Or maybe
that's a result of something I changed early on and didn't quite know
that would be an affect of my change?

Basically, I'm just trying to make this website as user-friendly as
possible in terms of handling errors and telling the users everything
is ok (they kind of need their hands held sometimes), as well as
reporting as many errors as possible to me in a more obvious manner,
instead of just putting them in a log file.
-David

[47computers]

Another question just came to me...

>From within the functions in that class, can I manually throw a kind of

custom error? Say, for example, the function runs a SELECT query on a
database and all the code executes just fine, but no records are
returned. For that particular function, records really _should_ be
returned. Otherwise, something is wrong.

Would there be a way, using the trapping I have in place, to throw an
error with a custom message? Because the only other way I can think of
doing it would be to have a function within the class that sends the
error reports that my custom error handler sends and call that function
within the class.

But, not only is it generally bad design to have to re-define the same
thing in multiple places (and, subsequently, change it in multiple
places if it ever needs to be changed), but that would require some
major changes to my code since the error handler also, within itself,
creates an instance of another class that's defined in another file.
Making a long story short, I'd have to pass that object as an argument
to every function in my first class (of which there are many) and
update all function calls throughout the project. (Unless there's a
way to define an instance of the second class within the first class.
But wouldn't that require including the second class's file within the
constructor of the first class? Isn't that... messy?)
-David

[ZeldorBlat]

47*********@gmail.com wrote:

What do you mean by "mess up a line" ? Change it to include invalid
syntax?

Ah, I see what you mean. When I "messed up a line" what I tried was a
typo to a function call (on a result set from a mysqli->query call, I'd
normally call fetch_assoc, but instead tried fletch_assoc, just to see
how it would break). It looks like that was outside the scope of the
custom error trapping capabilities.

When I, instead, just change the name of a variable being used, then it
traps a simple "undefined variable" error just fine.

Well, I guess as long as some errors are untrappable, that's fine. On
that note, does my trapping at least give me the full available scope?
(error_reporting(E_ERROR | E_PARSE);)

Before the script is run it gets parsed which includes checking the
syntax. If the syntax is invalid, nothing happens -- at all.

>
Also, for the errors outside of the custom error trapping scope (such
as parser errors), the default response from the user's perspective is
to just see a blank page. Is there any way to change that? Or maybe
that's a result of something I changed early on and didn't quite know
that would be an affect of my change?

Basically, I'm just trying to make this website as user-friendly as
possible in terms of handling errors and telling the users everything
is ok (they kind of need their hands held sometimes), as well as
reporting as many errors as possible to me in a more obvious manner,
instead of just putting them in a log file.

Hopefully by the time your code gets into production you won't have any
syntax errors. You did at least try to run the script before putting
it out there, right?

[ZeldorBlat]

[e-mail] wrote:

Another question just came to me...

From within the functions in that class, can I manually throw a kind of

custom error? Say, for example, the function runs a SELECT query on a
database and all the code executes just fine, but no records are
returned. For that particular function, records really _should_ be
returned. Otherwise, something is wrong.

Would there be a way, using the trapping I have in place, to throw an
error with a custom message? Because the only other way I can think of
doing it would be to have a function within the class that sends the
error reports that my custom error handler sends and call that function
within the class.

Look at trigger_error()
<http://www.php.net/trigger_error>

But you may really want to be using exceptions for the case described
above.

[47computers]

Hopefully by the time your code gets into production you won't have any

syntax errors. You did at least try to run the script before putting
it out there, right?

Oh, this is all in a testing environment, of course. I'm months away
from anything that can be considered "production" by any means. I'm
just trying to cover all the bases, is all. A parser error is just an
example, but what I'm just trying to ensure is that errors in general
are handled gracefully from the users' perspectives.

In general, I'd rather plan for it and not need it than need it and not
plan for it.
-David

[47computers]

Look at trigger_error()

<http://www.php.net/trigger_error>

But you may really want to be using exceptions for the case described
above.

This has definitely sent me in the right direction, thank you :)

Hopefully one last question: Suppose I enclose my function's code
within a try/catch. When I want to manually error out, I throw a new
Exception with the error message I want. From a design perspective,
what _should_ I be doing in that catch block?

Currently, for my testing, I'm just calling trigger_error in the catch
block to execute my custom error handler which is working like a charm.
Is this bad form in any way? This may be a silly question, but I
figure it's worth asking.
-David

[ZeldorBlat]

47*********@gmail.com wrote:

Look at trigger_error()
<http://www.php.net/trigger_error>

But you may really want to be using exceptions for the case described
above.

This has definitely sent me in the right direction, thank you :)

Hopefully one last question: Suppose I enclose my function's code
within a try/catch. When I want to manually error out, I throw a new
Exception with the error message I want. From a design perspective,
what _should_ I be doing in that catch block?

Currently, for my testing, I'm just calling trigger_error in the catch
block to execute my custom error handler which is working like a charm.
Is this bad form in any way? This may be a silly question, but I
figure it's worth asking.
-David

The beauty of exceptions is that if you want to handle them you can, or
you can let someone else handle them, or you can not handle them at
all. Furthermore, you can decide what to do with it based on some sort
of condition. So, for example you might say:

try {
//do something that might throw an exception with code = 1
//do something that might throw an exception with code = 2
} catch (Exception $e) {
if($e->getCode() == 1) {
//I will gracefully handle the exception when the code is 1
}
else {
throw $e; //let someone else deal with it
}
}

[mootmail-googlegroups]

ZeldorBlat wrote:

47*********@gmail.com wrote:

Look at trigger_error()
<http://www.php.net/trigger_error>
>
But you may really want to be using exceptions for the case described
above.

This has definitely sent me in the right direction, thank you :)

Hopefully one last question: Suppose I enclose my function's code
within a try/catch. When I want to manually error out, I throw a new
Exception with the error message I want. From a design perspective,
what _should_ I be doing in that catch block?

Currently, for my testing, I'm just calling trigger_error in the catch
block to execute my custom error handler which is working like a charm.
Is this bad form in any way? This may be a silly question, but I
figure it's worth asking.
-David

The beauty of exceptions is that if you want to handle them you can, or
you can let someone else handle them, or you can not handle them at
all. Furthermore, you can decide what to do with it based on some sort
of condition. So, for example you might say:

try {
//do something that might throw an exception with code = 1
//do something that might throw an exception with code = 2
} catch (Exception $e) {
if($e->getCode() == 1) {
//I will gracefully handle the exception when the code is 1
}
else {
throw $e; //let someone else deal with it
}
}

Extending upon that example, Exceptions can also give you a greater
granularity as to the TYPE of errors that occur. By inheriting the
base Exception class into your own customized versions, you can have
multiple types of exceptions that are handled differently. So not only
can you decide whether to handle an exception or throw it up the stack,
but you can also handle each type in it's own way. For example, adding
to the quoted example above:

try {
//do something that might throw an exception with code = 1
//do something that might throw an exception with code = 2
} catch (DatabaseException $e) {
//my query returned no results, so I want to handle that right here
} catch (Exception $e) {
//a generic exception occured
if($e->getCode() == 1) {
//I will gracefully handle the exception when the code is 1
}
else {
throw $e; //let someone else deal with it
}
}