Code please.

Hi there penders,

You set the error_reporting(E_ALL|E_STRICT); at the top of the script and whilst loading __autoloader does its thing, it fails? I don't do much with __autoloader() but from what I understand, it's set outside the class or inside, much like the __construct() isn't it?

As L33t_jordan asks, could you post the offending function, maybe there will be something obvious to a fresh pair of eye's ;)

Cheers,
MRb

I'm wondering if I'm missing something here...?!

Yes, and I believe it is here ...

I'm also setting a custom error handler with set_error_handler()

You said it was a parse error and from the notes on that function page you can see ...

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.

set_error_handler [php.net]

Thanks for your replies, I've actually figured out what was going on...

@coopster - Sorry, my comment about the custom error handler and it not being triggered was a bit misleading. Yes, a custom error handler cannot trap parse errors, but nor was it being triggered for 'less serious' E_USER errors etc.

No error of any kind was being output or logged because the error_reporting level was somehow being set to 0. At first I thought this was just within the __autoload() function but that wasn't quite so.

Basically, I had something like this:

error_reporting(E_ALL | E_STRICT); 
ini_set('display_errors','On'); 
trigger_error('This error is output - OK'); 
function __autoload($className) { 
 // At the point in question, error_reporting() was returning 0! 
 echo 'ERROR REPORTING IS SET TO: '.error_reporting(); 
 trigger_error('This error is NOT output or logged!'); 
 // Rest of script... include necessary file for class etc. 
 // If included file contained a fatal error NOTHING was logged - script justed halted here 
} 

Elsewhere in the code I was including a file, but (erroneously) suppressing errors on the include:

@include 'somefile.php';

Suppressing errors with '@' results in error_reporting() temporarily being set to 0, and code in the included file was resulting in __autoload() being triggered. Oops!

Hi there penders,

@include 'somefile.php';

IMHO - always a bad idea to suppress error messages, I should think that if there is anything wrong coding wise, that you would want to know what it could be and fix it - though it can be used in some XML functions to mask error's (non-serious) when retrieving data from other URL's, this up to yet is the only exception I have seen.

Glad as you have got it sorted out now - personally I can't see the use in having the __autoload function - I guess I haven't had reason enough to use it yet.

Cheers,
MRb

As you mention, there are perfectly valid reasons for occasionally using the error control operator '@', although that was indeed the problem in this case as it turns out. However, 'somefile.php' could actually contain some user generated content so that was the thought behind this particular instance. Custom error handlers are still called when errors are suppressed (when error_reporting is 0) - but obviously not parse errors (as mentioned above) and if track_errors is enabled you can check the last error that was suppressed.

__autoload() can be a great way to manage your class libraries (and perhaps other included files), rather than having require_once() all over the place (which is harder to maintain and can be slow). Must admit I initially thought it was a bit lazy, but it actually helps to create better code.

but obviously not parse errors

I was under the impression you can pick up parse errors if you are running a script like this:

<?php

require 'file_with_syntax_errors.php';

echo my_error_handling_function();

?>

Or am I mistaken?

I can't see how that script would 'pick up' parse errors?

<?php  
require 'file_with_syntax_errors.php'; <<-- Script would halt here with fatal error 
echo my_error_handling_function(); <<-- Won't execute 
?>

There might be ways to trap errors that may not be handled by a custom error handler (see comments on PHP's set_error_handler() manual page [uk.php.net]), but I don't believe that true parse (syntax) errors can be trapped by any programmatic method, since they occur before code execution (when the code is being parsed)?