| Justin Patrin 2005-11-01, 3:56 am |
| On 10/31/05, Ian Eure <ieure@php.net> wrote:
> Alan Knowles wrote:
>
>
> I don't think the cause is relevant, but the effect, which is
> uniformly confusing - i.e. "why am I getting a blank page and seeing
> no errors."
>
I am always being bitten by @ silencing includes where I have a parse
error. I have to dig down into the code to find the offending call and
un-silence it. Ugh. Yes, "blank page syndrome" is why this should be
introduced.
>
> Greg, your original reply was missing, so I'm replying to it here.
>
>
> I'm not sure this is really a problem in this case - factory() methods
> are supposed to load a single kind of object, so if they're stored
> uniformly and named consistently, the include_path stuff isn't needed.
> And I think that's a good thing.
>
> I've certainly never needed to iterate over the include_path for cases
> like that. Have you run into scenarios where this is necessary?
There are 2 schools of thought on this. 1 is factories / includes
should never create a PHP error. This leads to either silencing the
call with @ (horrible) or iterating over the include_path
(inefficient). The other is just to let the PHP error happen like
normal. I'm currently for the second option. If an include fails it's
more of a development / installation issue. It should show up as a
normal PHP error and be dealt with like a normal PHP error (same as a
parse error). In production, this is easy enough to silence with
error_reporting and easy enough to catch with an error handler. IMHO
there's no need for extra include_path and file_exists processing when
PHP is doing it for us.
Of course the best solution would be if PHP5 would throw an exception
if a file isn't found or there's a parse error. Of course, I'm sure
I'm dreaming....
--
Justin Patrin
|