Hi,
I think it would be useful if require would throw an exception on failure.
Currently one would use @include in order to load in a file that could
be missing or could contain parse errors. However it is impossible to
easy find out if the file was missing, had parse errors or returned false.
Please also note that file_exists() doesnt check the include path and a
check like this also opens up the chance for race conditions etc.
By throwing an exception inside require with the necessary information
it would be able to cleanly handle this situation without having to
silence this error and then parsing the error message. And it would
obviously be BC compatible as uncaught exceptions are fatal.
regards,
Lukas Smith
I think it would be useful if require would throw an exception on failure.
NO! Internal functions do NOT throw exceptions, period.
By throwing an exception inside require with the necessary information
it would be able to cleanly handle this situation without having to
silence this error and then parsing the error message. And it would
obviously be BC compatible as uncaught exceptions are fatal.
A require should fail if it can't find the file, no nice handling as
it's CLEARLY a programmers error.
regards,
Derick
Hehe, shut down Lukas.
I'd love to know why file_exists doesn't search the include path like every
other file function
"Derick Rethans" derick@php.net wrote in message
news:Pine.LNX.4.58.0405081253550.10150@localhost...
I think it would be useful if require would throw an exception on
failure.NO! Internal functions do NOT throw exceptions, period.
By throwing an exception inside require with the necessary information
it would be able to cleanly handle this situation without having to
silence this error and then parsing the error message. And it would
obviously be BC compatible as uncaught exceptions are fatal.A require should fail if it can't find the file, no nice handling as
it's CLEARLY a programmers error.regards,
Derick
Derick Rethans wrote:
By throwing an exception inside require with the necessary information
it would be able to cleanly handle this situation without having to
silence this error and then parsing the error message. And it would
obviously be BC compatible as uncaught exceptions are fatal.A require should fail if it can't find the file, no nice handling as
it's CLEARLY a programmers error.
Actually I was essentially suggesting a way to make include superfluous
(to some extend anyways). The issue I am trying to resolve, as I
described in the original mail, was to better handle condition includes.
If you want to conditionally include some code it is currently not
possible to easily (as in not having to parse error messages) determine
if one of the following has happends:
- the file is missing
- the file had parse errors
- the file simply returned false
While case 3) I have never come across in real life it still means that
- and 2) are problematic.
file_exists()obviously is not sufficient to
determine 1) if you use the include path directive. So why would you
want to know (and therefore why would simply silencing with @ not be
sufficient)?
For example you have a framework with optional functionality that the
user needs to install/enable/buy. Or you are loading modules on demand
which may be structured in several ways (the first example is better
then this second example). In order to better inform the user why a
certain feature is unavailable you obviously want to be able to
differentiate between the two .. since only one of them really is an
error. It simply makes debugging easier.
I think this is a very real problem and it would be nice to have a
solution which does not require user land extensions to file_exists() or
error message parsing.
Again the solution I suggested would very cleanly handle this imho, but
I am open to other solutions (allthough I wouldnt mind not having to add
some additional functional call like an extended version of
file_exists() ..).
regards,
Lukas Smith
smith@backendmedia.com
BackendMedia
www.backendmedia.com
berlin@backendmedia.com
Linn Zwoch Smith GbR
Pariser Str. 44
D-10707 Berlin
Tel +49 30 83 22 50 00
Fax +49 30 83 22 50 07