php-general Digest 14 May 2011 10:33:25 -0000 Issue 7310

Topics (messages 312782 through 312786):

Re: Running PHP5 in a PHP4 environment
        312782 by: Per Jessen
        312783 by: Lester Caine
        312784 by: Alain Williams
        312785 by: Daniel Brown

Error recovery - fatal errors
        312786 by: Tim Streater

Administrivia:

To subscribe to the digest, e-mail:
        [email protected]

To unsubscribe from the digest, e-mail:
        [email protected]

To post to the list, e-mail:
        [email protected]


----------------------------------------------------------------------
--- Begin Message ---
Paul M Foster wrote:

> I recently installed some code written for a PHP 5 environment on a
> server which I thought was running PHP 5. It was a form which should
> have painted at least something to the browser window. But instead, I
> got a complete blank page. Come to find out that the server was
> actually running PHP 4.
> 
> I've seen PHP do this before-- trying to run PHP 5 in a PHP 4
> environment causes it to do every step up to the point where it sees
> "future code" it doesn't understand. Then it just stops, no errors, no
> panics, no nothing.
> 
> Is this expected behavior, or am I missing something? It seems like if
> the PHP interpreter hit some "future code" it didn't understand, it
> would issue a syntax warning or something similar. Is there some way I
> can squeeze some identifiable error code out of PHP 4 to indicate it's
> hit PHP 5 code it doesn't understand?

Check the apache error logs, that is where you will usually find
something.


-- 
Per Jessen, Zürich (14.2°C)


--- End Message ---
--- Begin Message ---
Per Jessen wrote:
Check the apache error logs, that is where you will usually find
something.

And switching on error display in php.ini helps as well while you are debugging.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--- End Message ---
--- Begin Message ---
On Fri, May 13, 2011 at 01:22:10AM -0400, Paul M Foster wrote:
> I recently installed some code written for a PHP 5 environment on a
> server which I thought was running PHP 5. It was a form which should
> ...
> would issue a syntax warning or something similar. Is there some way I
> can squeeze some identifiable error code out of PHP 4 to indicate it's
> hit PHP 5 code it doesn't understand?

Would your time not be better spent getting the system upgraded to PHP5 ?

PHP 4 was depricated some time ago.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

--- End Message ---
--- Begin Message ---
On Fri, May 13, 2011 at 04:14, Alain Williams <[email protected]> wrote:
>
> PHP 4 was depricated some time ago.

    Not just deprecated --- we EOL'd it back in 2007[1] (and let it
completely die on 08-08-08).  If you can upgrade PHP on the box, you
probably (read: really!) should; if not, time to find a new host.


        ^1. http://links.parasane.net/rzrp

-- 
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/

--- End Message ---
--- Begin Message ---
I would like, in my app, to recover from as many run-time errors as possible, 
so that I can tidy up. And unsolicited output generated by the standard error 
system is really unhelpful as it becomes part of the ajax reply to the browser.

So I've added my own error handler, but it seems that I can't catch fatal 
errors. The error in question comes from doing something like:

$res = $dbh->query ($sql);

with $sql being an SQL statement, and $dbh being a database handle. I recently 
had a case where $dbh was NULL, which triggers a fatal error from SQLite. In 
principle such a bug should show up quickly, but this one had lain untriggered 
for about a year. It seems to me somewhat arbitrary for this to be designated a 
fatal error. Is there a way I can catch these? Most SQLite error situations I'm 
solving with try/catch but no luck with this one so far.

Error handling in library packages seems somewhat arbitrary - e.g. opendir may 
give an E_WARNING, but closedir, readdir don't.

tim


--- End Message ---

Reply via email to