Exception vs error handling

[john6630]

Coming from the .Net world, I am used to the try...catch...finally
approach to error handling. And PHP 5 now supports this approach. But
I am not clear what happens to unhandled errors/exceptioins? Do I
define a default error handler as well as do my try/catch? Can I mix
error handling with the exceptions? Is one approach better than the
other?

TIA
John

[Dale]

"john6630" <jo******@hotmail.comwrote in message
news:1b**********************************@r15g2000 prd.googlegroups.com...

Coming from the .Net world, I am used to the try...catch...finally
approach to error handling. And PHP 5 now supports this approach. But
I am not clear what happens to unhandled errors/exceptioins? Do I
define a default error handler as well as do my try/catch? Can I mix
error handling with the exceptions? Is one approach better than the
other?

try/catch is not .NET exlusive. further, you are coming from a VB.NET
background...as try/catch has been a part of MOST *other* languages
supported by .net, i.e. c, c++, c#, perl, etc. since before the advent of
..NET.

anyway, what happens when you don't handle an exception in any other
language? you get an unrecoverable crash...or your language's error handler
handles it as best it can. php is no different.

you should plan and design the way you want errors handled. if you want to
beautify the output of the default error handler, by all means, tie into it.
as for other methods...*always* try and handle any error you might
encounter. if you don't, you will find yourself with a potential memory leak
and your errors will show to your customers in an ugly fashion with
jibberish-for-a-description of the problem.

but, that's just me.

cheers

[WalterGR]

On Aug 19, 7:06 pm, john6630 <[e-mail]:

Coming from the .Net world, I am used to the try...catch...finally
approach to error handling. And PHP 5 now supports this approach. But
I am not clear what happens to unhandled errors/exceptioins? Do I
define a default error handler as well as do my try/catch? Can I mix
error handling with the exceptions? Is one approach better than the
other?

TIA
John

PHP doesn't support "finally."

But in its most commonly deployed configuration, it does like to dump
warning/error messages in the middle of your output, as Dale alluded
to.

My advice:

Turn up error_reporting as far as it can go: E_ALL | E_STRICT.

Turn all PHP warnings/errors into exceptions using something like the
following:

set_error_handler( create_function( '$x, $y', 'throw new PHPError( $y,
$x );' ), E_ALL | E_STRICT );

Then handle the exceptions as appropriate.

(If you use 3rd party libraries, you'll find they aren't always so
strict about their error handling. If you find that's the case, post
again here and I'll describe how I handle it.)

Walter

[Sjoerd]

I agree with your post, but want to add some things to it.

On Aug 20, 7:45*am, WalterGR <[e-mail]:

But in its most commonly deployed configuration, it does like to dump
warning/error messages in the middle of your output, as Dale alluded
to.

Indeed. In development environments this is probably fine and you want
errors to stand out. In a production environment it is typical to
disable error messages altogether.

You may handle uncatched exceptions by using set_exception_handler()

By default, PHP functions do not throw exceptions but indicate failure
by their return value. For example, fopen() returns a file handle on
success and FALSE on failure. However, you do want exceptions to be
thrown instead, so Walter proposes this:

Turn all PHP warnings/errors into exceptions using something like the
following:

set_error_handler( create_function( '$x, $y', 'throw new PHPError( $y,
$x );' ), E_ALL | E_STRICT );

The created function indeed throws an exception. It is called whenever
an error occurs. Note that this will not use the settings of
error_reporting().

[john6630]

On Aug 20, 12:20 am, Sjoerd <[e-mail]:

I agree with your post, but want to add some things to it.

On Aug 20, 7:45 am, WalterGR <[e-mail]:

But in its most commonly deployed configuration, it does like to dump
warning/error messages in the middle of your output, as Dale alluded
to.

Indeed. In development environments this is probably fine and you want
errors to stand out. In a production environment it is typical to
disable error messages altogether.

You may handle uncatched exceptions by using set_exception_handler()

By default, PHP functions do not throw exceptions but indicate failure
by their return value. For example, fopen() returns a file handle on
success and FALSE on failure. However, you do want exceptions to be
thrown instead, so Walter proposes this:

Turn all PHP warnings/errors into exceptions using something like the
following:

set_error_handler( create_function( '$x, $y', 'throw new PHPError( $y,
$x );' ), E_ALL | E_STRICT );

The created function indeed throws an exception. It is called whenever
an error occurs. Note that this will not use the settings of
error_reporting().

Yes, my programming is in VB.Net and, indeed, the purpose of my
question is so I can create an error handling framework for my
application before I begin writing code. The confusion for me is in
the concept of "errors" vs "exceptions". We have set_error_handler and
set_exception_handler. We have trigger_error and "throw new
exception". Understanding which occurs when is my question.

Thank you for the responses and I believe I am beginning to
understand. I would like to summarize what I understand just to be
sure I have it correctly.

Exceptions are a result of my anticipation of an error. For example,
if I anticipate a problem connecting to a database, I can enclose that
code in a try/catch and throw an exception within the code block if I
detect the connection failed.

Errors on the other hand are generated by PHP automatically. So I need
to define an error handler (assuming I do not want to use the default
handler).

And then the good advice here was to use set_error_handler to throw
all errors as exceptions to a generic handler (which is analogous to
my UnhandledExceptionHandler in vb.net)

Do I have that correct?

If so, I have another question. In the set_error_handler example
above, you only pass the error code and error string. Wouldn't it be
good to also pass the file, line and context? I saw some code that
automatically detected if the app is running locally and uses the
added info for a "debug" mode of display but shortens to a user
friendly display if the site is deployed.

I hope my questions are not too sophomoric, but being new to the web
world, there is a lot to learn and a lot left to the developer that
was handled by the OS or IDE. I also find it interesting that even
though error handling is a key requirement of any app, most of the
books I have read give it only passing consideration.

Thanks again,
John

[WalterGR]

On Aug 20, 10:19*am, john6630 <[e-mail]:

Fantastic Walter...it is beginning to make sense. I had reviewed the
PHP manual but did not understand how to use the info.

So I have one last question...do I need to use both set_error_handler
and set_exception_handler to prevent any unhandled errors or
exceptions? I was thinking that since you used set_error_handler, that
would take care of everything, but you indicate your log was from an
uncaught exception, so now I think I need to allow for both errors and
exceptions.

Thanks again,
John

Very glad I can help.

set_error_handler only handles PHP errors, so yes, you do need a way
to handle uncaught exceptions. The easiest way is - as you mention -
set_exception_handler.

Now, this is where my knowledge gets shaky:

As I understand it - and I hope someone will correct me if I'm wrong -
the unfortunate thing about defining your own exception handler is
that you lose the built-in functionality of PHP's default exception
handler. That means: you lose the fancy stack trace output, and you
lose PHP's automatic logging of that output. (Beware that there are
configuration settings to turn on logging, which may be off by default
in your configuration.)

You may have to write a default exception handler that replicates that
functionality.

My hypothesis - which I haven't yet checked - is that you may be able
to call the default exception handler from your user-defined exception
handler. (When you call set_exception_handler it gives you the name
of the previous exception handler.) But the default exception handler
halts execution, so you'd have to make *sure* that the HTML error page
has been fully sent to the user before calling it.

Walter

[WalterGR]

There's one other thing I should point out.

Handling PHP errors this way (i.e. converting them to exceptions)
isn't necessarily fully supported in PHP. In other words, you may
sometimes get unexpected results. (Though as there's no specification
for PHP, "unexpected" is left for you to define.)

From my experience, I can give you only one example, though there are
probably others. Sometimes all the uncaught exception message will
contain is:

"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"

If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."

Another example is provided in this comment:

http://www.php.net/manual/en/functio...dler.php#68712

Walter

[john6630]

On Aug 20, 10:53 am, WalterGR <[e-mail]:

There's one other thing I should point out.

Handling PHP errors this way (i.e. converting them to exceptions)
isn't necessarily fully supported in PHP. In other words, you may
sometimes get unexpected results. (Though as there's no specification
for PHP, "unexpected" is left for you to define.)

From my experience, I can give you only one example, though there are
probably others. Sometimes all the uncaught exception message will
contain is:

"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"

If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."

Another example is provided in this comment:

http://www.php.net/manual/en/functio...dler.php#68712

Walter

Hi Walter,
Thank you so much for your time and sharing your expertise! I will
read and re-read your input as I define my error/exception handling
process but you have definitely placed me on the right path.

Thanks!
John

[WalterGR]

On Aug 20, 10:53*am, WalterGR <[e-mail]:

There's one other thing I should point out.

...

Sometimes all the uncaught exception message will contain is:

"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"

If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. *When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."

Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.

In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.

So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.

Walter
[1] http://php.benscom.com/manual/en/lan...oop5.decon.php

[Michael Fesser]

..oO(WalterGR)

>set_error_handler only handles PHP errors, so yes, you do need a way
to handle uncaught exceptions. The easiest way is - as you mention -
set_exception_handler.

Now, this is where my knowledge gets shaky:

As I understand it - and I hope someone will correct me if I'm wrong -
the unfortunate thing about defining your own exception handler is
that you lose the built-in functionality of PHP's default exception
handler. That means: you lose the fancy stack trace output, and you
lose PHP's automatic logging of that output. (Beware that there are
configuration settings to turn on logging, which may be off by default
in your configuration.)

You can easily get the backtrace by calling the exception method
getTraceAsString(). Check the manual for other helpful methods.

http://www.php.net/manual/en/language.exceptions.php

>You may have to write a default exception handler that replicates that
functionality.

Exactly. You can also use your own logging mechanism then (plain file,
database, syslog, ...)

Micha

[john6630]

On Aug 21, 2:47 am, WalterGR <[e-mail]:

On Aug 20, 10:53 am, WalterGR <[e-mail]:

There's one other thing I should point out.

...

Sometimes all the uncaught exception message will contain is:

"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"

If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."

Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.

In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.

So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.

Walter

[1]http://php.benscom.com/manual/en/language.oop5.decon.php

Hi Walter,
Sorry to bother you again, but I have yet one more question.

I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?

Thanks again for all the help,
John

[Jerry Stuckle]

john6630 wrote:

On Aug 21, 2:47 am, WalterGR <[e-mail]:

>On Aug 20, 10:53 am, WalterGR <[e-mail]:

>>There's one other thing I should point out.

...

>>Sometimes all the uncaught exception message will contain is:
"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"
If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."

Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.

In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.

So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.

Walter

[1]http://php.benscom.com/manual/en/language.oop5.decon.php

Hi Walter,
Sorry to bother you again, but I have yet one more question.

I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?

Thanks again for all the help,
John

You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[john6630]

On Aug 22, 10:46 am, Jerry Stuckle <[e-mail]:

john6630 wrote:

On Aug 21, 2:47 am, WalterGR <[e-mail]:

On Aug 20, 10:53 am, WalterGR <[e-mail]:

>There's one other thing I should point out.
...
Sometimes all the uncaught exception message will contain is:
"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"
If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."
Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.

In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.

So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.

Walter

[1]http://php.benscom.com/manual/en/language.oop5.decon.php

Hi Walter,
Sorry to bother you again, but I have yet one more question.

I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?

Thanks again for all the help,
John

You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,
I mispoke, I really meant, to create and serve a page based on the
error. Here is the outline of what I think I need to do:

<?php

function customerror($type, $msg, $file, $line, $context){
@ob_end_clean(); // get rid of any half-parsed page
include_once("myErrorHandlerPage.php");
die();
}
// define custom error handler
set_error_handler("customerror");

ob_start();

?>

// put my page html and php code here

<?php
ob_end_flush();
?>

What I believe this will allow me to do is to create a special page in
myErrorHandlerPage.php that uses the error parameters passed into
customerror and create the output I want the user to see.

So is this a good idea? Or are there better ways. I have been
searching the web hoping to find a script or example of what I want to
do and could not find one.

Thanks,
John

[john6630]

On Aug 22, 11:47 am, john6630 <[e-mail]:

On Aug 22, 10:46 am, Jerry Stuckle <[e-mail]:

john6630 wrote:

On Aug 21, 2:47 am, WalterGR <[e-mail]:
>On Aug 20, 10:53 am, WalterGR <[e-mail]:

>>There's one other thing I should point out.
>...
>>Sometimes all the uncaught exception message will contain is:
>>"Fatal error: Exception thrown without a stack frame in Unknown on
>>line 0"
>>If you ever see that, uncomment the set_error_handler line and see
>>what PHP would ordinarily do. When I encountered it, PHP returned the
>>(fairly common) "Warning: Cannot modify header information - headers
>>already sent by..."
>Okay, I found an explanation for this behavior. If an object is not
>garbage collected before script execution ends (e.g. if its referring
>variables aren't set to null) then its destructor is called at the
>time of script termination.[1] There is no stack. If a destructor
>throws an exception at this time, it results in the fatal error shown
>above.

>In my particular case, the destructor of one of my objects was trying
>to modify headers after they had already been sent. That would
>normally result in a PHP warning, but it got converted to an exception
>which was then thrown in the destructor, and then resulted in the less-
>than-descriptive fatal error.

>So in short - if you see the fatal error, comment out the
>set_error_handler call, and you'll probably find a destructor that's
>throwing an exception.

>Walter

>[1]http://php.benscom.com/manual/en/language.oop5.decon.php

Hi Walter,
Sorry to bother you again, but I have yet one more question.

I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?

Thanks again for all the help,
John

You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,
I mispoke, I really meant, to create and serve a page based on the
error. Here is the outline of what I think I need to do:

<?php

function customerror($type, $msg, $file, $line, $context){
@ob_end_clean(); // get rid of any half-parsed page
include_once("myErrorHandlerPage.php");
die();}

// define custom error handler
set_error_handler("customerror");

ob_start();

?>

// put my page html and php code here

<?php
ob_end_flush();
?>

What I believe this will allow me to do is to create a special page in
myErrorHandlerPage.php that uses the error parameters passed into
customerror and create the output I want the user to see.

So is this a good idea? Or are there better ways. I have been
searching the web hoping to find a script or example of what I want to
do and could not find one.

Thanks,
John

On last (I hope) question. I should have asked this to begin with.
Does PHP ever throw exceptions or are they only created by scripts
throwing them? It is strange, in all that I have read, no where does
it answer this question specifically. And I guess another way of
asking this is, can PHP5 scripts only worry about errors and not use
exceptions?

Thanks,
John

[Jerry Stuckle]

Jerry Stuckle wrote:

john6630 wrote:

>On Aug 21, 2:47 am, WalterGR <[e-mail]:

>>On Aug 20, 10:53 am, WalterGR <[e-mail]:

There's one other thing I should point out.
...
Sometimes all the uncaught exception message will contain is:
"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"
If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."
Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.

In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.

So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.

Walter

[1]http://php.benscom.com/manual/en/language.oop5.decon.php

Hi Walter,
Sorry to bother you again, but I have yet one more question.

I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?

Thanks again for all the help,
John

You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).

I think it would be better to just include() the file with the error
display in it, i.e. where you detect the error:

$emsg = "Sorry, that didn't work.";

And later...

if (isset($emsg) && $emsg <'')
include('error_display.php');

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

john6630 wrote:

On Aug 22, 11:47 am, john6630 <[e-mail]:

>On Aug 22, 10:46 am, Jerry Stuckle <[e-mail]:

>>john6630 wrote:
On Aug 21, 2:47 am, WalterGR <[e-mail]:
On Aug 20, 10:53 am, WalterGR <[e-mail]:
>There's one other thing I should point out.
...
>Sometimes all the uncaught exception message will contain is:
>"Fatal error: Exception thrown without a stack frame in Unknown on
>line 0"
>If you ever see that, uncomment the set_error_handler line and see
>what PHP would ordinarily do. When I encountered it, PHP returned the
>(fairly common) "Warning: Cannot modify header information - headers
>already sent by..."
Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.
In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.
So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.
Walter
[1]http://php.benscom.com/manual/en/language.oop5.decon.php
Hi Walter,
Sorry to bother you again, but I have yet one more question.
I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?
Thanks again for all the help,
John
You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,
I mispoke, I really meant, to create and serve a page based on the
error. Here is the outline of what I think I need to do:

<?php

function customerror($type, $msg, $file, $line, $context){
@ob_end_clean(); // get rid of any half-parsed page
include_once("myErrorHandlerPage.php");
die();}

// define custom error handler
set_error_handler("customerror");

ob_start();

?>

// put my page html and php code here

<?php
ob_end_flush();
?>

What I believe this will allow me to do is to create a special page in
myErrorHandlerPage.php that uses the error parameters passed into
customerror and create the output I want the user to see.

So is this a good idea? Or are there better ways. I have been
searching the web hoping to find a script or example of what I want to
do and could not find one.

Thanks,
John

On last (I hope) question. I should have asked this to begin with.
Does PHP ever throw exceptions or are they only created by scripts
throwing them? It is strange, in all that I have read, no where does
it answer this question specifically. And I guess another way of
asking this is, can PHP5 scripts only worry about errors and not use
exceptions?

Thanks,
John

I can't think of any of the base PHP code which throws exceptions, but I
could be missing something. However, several of the libraries can, such
as PDO, DOM, etc.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[john6630]

On Aug 22, 1:40 pm, Jerry Stuckle <[e-mail]:

john6630 wrote:

On Aug 22, 11:47 am, john6630 <[e-mail]:

On Aug 22, 10:46 am, Jerry Stuckle <[e-mail]:

>john6630 wrote:
On Aug 21, 2:47 am, WalterGR <[e-mail]:
On Aug 20, 10:53 am, WalterGR <[e-mail]:
There's one other thing I should point out.
...
Sometimes all the uncaught exception message will contain is:
"Fatal error: Exception thrown without a stack frame in Unknown on
line 0"
If you ever see that, uncomment the set_error_handler line and see
what PHP would ordinarily do. When I encountered it, PHP returned the
(fairly common) "Warning: Cannot modify header information - headers
already sent by..."
Okay, I found an explanation for this behavior. If an object is not
garbage collected before script execution ends (e.g. if its referring
variables aren't set to null) then its destructor is called at the
time of script termination.[1] There is no stack. If a destructor
throws an exception at this time, it results in the fatal error shown
above.
In my particular case, the destructor of one of my objects was trying
to modify headers after they had already been sent. That would
normally result in a PHP warning, but it got converted to an exception
which was then thrown in the destructor, and then resulted in the less-
than-descriptive fatal error.
So in short - if you see the fatal error, comment out the
set_error_handler call, and you'll probably find a destructor that's
throwing an exception.
Walter
[1]http://php.benscom.com/manual/en/language.oop5.decon.php
Hi Walter,
Sorry to bother you again, but I have yet one more question.
I want to display my user error messages in a consistent and, if
possible, separate window. I am not sure how to do this since I do not
know where in the rendering of the page an error may occur. Do I use
output buffering and discard the buffer in my error handler so I can
display a new page. How is this done in a general way?
Thanks again for all the help,
John
You can't open a new window in PHP (or any other server-side language).
You need a client-side language such as javascript (which could
interface to PHP on the server end, i.e. via AJAX).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
I mispoke, I really meant, to create and serve a page based on the
error. Here is the outline of what I think I need to do:

<?php

function customerror($type, $msg, $file, $line, $context){
@ob_end_clean(); // get rid of any half-parsed page
include_once("myErrorHandlerPage.php");
die();}

// define custom error handler
set_error_handler("customerror");

ob_start();

?>

// put my page html and php code here

<?php
ob_end_flush();
?>

What I believe this will allow me to do is to create a special page in
myErrorHandlerPage.php that uses the error parameters passed into
customerror and create the output I want the user to see.

So is this a good idea? Or are there better ways. I have been
searching the web hoping to find a script or example of what I want to
do and could not find one.

Thanks,
John

On last (I hope) question. I should have asked this to begin with.
Does PHP ever throw exceptions or are they only created by scripts
throwing them? It is strange, in all that I have read, no where does
it answer this question specifically. And I guess another way of
asking this is, can PHP5 scripts only worry about errors and not use
exceptions?

Thanks,
John

I can't think of any of the base PHP code which throws exceptions, but I
could be missing something. However, several of the libraries can, such
as PDO, DOM, etc.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Thanks for the fast response Jerry. I was thinking that all newer code
(i.e. libraries) will probably use exceptions. But that should also be
documented for the api being exposed, I would hope.

Also how to handle the user display of error data will depend, I
think, on the context of the error. I created a small test page and
triggered errors and threw exceptions at various points in the page.
What I want to avoid is having part of a page displayed and then have
an error message that seems out of place. So in that case, abandoning
the original page and displaying an error box, would be best. In other
cases, an in-line message may be preferable. This is all new to me. In
the VB.Net world, I wrote a generic error handler and that was used in
all situations and worked just fine. So I am just learning this brave
new world of web applications (and I see very important distinctions
between web applications and web sites and what might work in one case
may not be applicable in the other). I am very grateful to you and
everyone on this group for the time and effort put forth.

Thanks,
John