Hi,
I agree with Danīs opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality always run
into complications. And that was what happen on PHP4,
where OO (although good) was the art of
"workarounds"...
IMHO It should be possible to throw exceptions from
anywhere and the exception should be caught not matter
of the scope it is.
The reason for that is simple:
that way, we would not get forced to work with, or
implement, always TWO set of classes/methodes of
"error handlers"(one for errors and other for
exceptions) on libraries, APIs or even applications.
Or use workarounds to create a set of methodes of
error handling using Output Buffering encapsulated
into OO code to get rid of the Fatal Errors for
example. That should not be necessary. With Exceptions
it would be very easier.
And It should be possible to tell the engine to trhow
exceptions instead of errors. Because if it is not
possible, we ran into the same problem above. (forgive
me if it is being implemented now, Iīm travelling
since september and canīt follow deep the dev).
But its only my opinion of course.
thanks,
Eduardo R. Maciel
>
> Hi Andi-
>
> Yes, that explains things and makes perfect sense if
> you are just
> writing your
> own web application. Now, consider the new
> __autoload
> functionality from
> a PEAR
> or other large API/library developer standpoint.
>
> The new __autoload functionality lets us:
> - Keep library usage/installation simple by only
> requiring the user to
> include one
> include file regardless of how many possible
> classes or other files
> may be
> needed. This 'initialization' file will setup a
> special autoloader
> for just that library.
> If the user happens to use their own autoloader,
> then they have to
> simply
> setup something like- if (eregi('^libclass_',
> $className)) {
> somelib::autoload($className); }
> A 1, with an optional 2 step install process,
> regardless of which
> parts of the
> library may be used is a good thing. :)
> - Keeps the performance of the library up because
> it
> now only needs to
> load
> class objects the user actually uses.
>
> The new exception handling also lets a library
> developer easily document
> and let a
> user know that mylib will throw exception x, y and
> z.
>
> With that in mind, it's always good practice when
> writing an API/library
> to throw the
> most informative errors possible. Normally, this
> would
> also include
> errors such as
> "Unable to initialize library 'mylib' because file
> 'foo.inc' could not
> be found. Please check
> install documentation.". A much nicer
> exception/error
> than Fatal Error
> in mylib. This
> would also allow the user to catch the error and
> handle it themself, and
> at their
> sole discretion choosing to continue on with script
> execution.
>
> These are just my thoughts and observations after
> writing a large
> API/library in
> PHP5-
>
> Dan Cox
>
> Andi Gutmans wrote:
>
> > Dan,
> >
> > __autoload() is the last chance to load a class
> which is needed before
> > erroring out and terminating the script. By
> design,
> if you don't take
> > advantage of this last chance the script will
> error
> out. Therefore,
> > throwing an exception inside the __autoload()
> function should not be
> > catchable by your script.
> >
> > I hope that explains things.
> >
> > Andi
> >
>
> --
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
