Hello Christian,
Wednesday, April 14, 2004, 2:31:12 PM, you wrote:
> Marcus Boerger wrote:
>> As i explained there is no good other way to tell the user the
>> ctor has failed. The two ways out out are:
> Personally I'd much prefer a way of returning a value from a
> constructor, i.e. to be able to 'return null;' or a similar language
> construct so I could do 'if ($db = new SQLiteDatabase)'
> It would also mean that I would run into a 'calling method on a
> non-object' error if I don't check it (which is fine).
In no language i know (c++, delphi, java as the popular ones) a ctor
can return a value especially not it's own value. The problem is that
when the ctor is called the object is already created. For most languages
that means some memory has been allocated and for php overloaded objects
like the SQLite class it also means that the memory has been initialized.
Now in PHP 4 there was the ugly trick of setting "$this=NULL".
To know how that worked you need to deeply understand PHP's GC. During
ctor execution $this is the only reference to the newly created instance.
Hence setting "$this=NULL" reduces the refcount to zero what deallocates
the object by calling it's ctor. The problem with this is that it could
never work correctly because evern after setting "$this=NULL" you still
need to be able to rely on a valid $this which you obviously can't.
> I strongly believe that we are talking about some basic initialization
> stuff to be done at the beginning of an application like creating a DB
> connection and setting up some environment only. Otherwise you'd imply
> that you start try/catching on every object instantation which is
> definitely not the way to go!
If you ask me i am pretty fine with (otherwise i wouldn't have made it so):
try {
$db = new SQLiteDatabase($file);
}
catch (Exception $e) {
// Code for no db-connection
exit(0);
}
// other code
And if you don't need code for "no-db-connection", well then you do not need
the try-catch-block at all. It is just a bit more typing you get used to
once you have learned it. And for me it is much better then having to use
an if-clause for every member access.
Maybe it is important to notice which internal objects may throw an
exception on failure.
On the otherhand it is possible to convert all warnings to exceptions in
user scripts. Together with the ability to control outpu buffering this is
a great gift:
try {
// some control code here: start-ob, error-handler-that-throws-exceptions
$db = new SQLiteDatabase($file);
// your normal code **without a single error-handling-if**
}
catch (Exception $e) {
// clear-ob
// Code for no db-connection
exit(0);
}
> Alternatively (something which works for PHP4 already) one could simply
> have a status a la
> $db = new SQLiteDatabase;
> if ($db->isValid)
> which is less elegant but based on the assumption that it has to be done
> at most 10 times in an application works just as well.
It not only has to be done in your PHP script but also internally at several
more places. So for me this is no option.
> In my opinion exceptions-for-ctor-failure is already a work-around
> abusing exceptions in an at least arguable way. You _require_ users to
> learn about a whole new (and complicated) paradigm in error handling
> which I'd very much avoid.
>> Hey if you want to work with OO then deal with all OO issues or
>> create ugly workarounds and don't pretend the language is OO at
> OO works very well without exceptions. Exceptions has to do with error
> handling, not with data encapsulation (which OO is about).
> Yes, I like OO. No I don't like exceptions. And I worked with both.
Me too, i use both where appropriate.
--
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
