# Exceptions and Errors

- Thread: https://externals.io/message/9161
- Original archive: https://news-web.php.net/php.internals/9161
- Started by Thies C.Arntzen on 2004-04-15T05:36:46+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #9161 — Thies C.Arntzen — 2004-04-15T05:36:46+00:00

URL: https://externals.io/message/9161#9161

Am 14.04.2004 um 21:53 schrieb Marcus Boerger:

> > […]
>
> 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".
>

i'm sure ZE2 can be tricked to support "return NULL" from a constructor 
so that:

$a = new bla();

if (! $a) ...


if ctors are the only place that *cannot* life without exceptions it 
would be well worth *fixing* (yes, i said fix), as adding 
"understanding exceptions" to the list of pre-requisites for 
learning/using php would just be a poor decision looking at what made 
php as popular as it is today.


thies

---

## #9166 — Andi Gutmans — 2004-04-15T06:26:52+00:00

URL: https://externals.io/message/9161#9166 · In reply to: #9161

I don't like these ideas. I think it should stay the way it is and not only 
because we're at RC2.
If Thies doesn't want to deal with this, then he can write constructors 
without logic. It's not that hard for the one in many classes where this 
might be needed.

Andi

At 08:20 AM 4/15/2004 +0200, Marcus Boerger wrote:
>Hello Thies,
>
>Return `NULL` wouldn't work because a ctor always returns `NULL` by
>default so we nee a trick. Would reallowing $this = `NULL` in ctors
>only and direct return and disallowing any other value be an option
>for (perhaps the executor can capture that event)? Would you like
>that?
>
>Aparat from that there were other possible solutions mentioned so
>far:
>
>The factory solution prevents inheritance on overloaded objects.
>If it would work the derived class needs to somehow be able to
>create a derived instance and still use the inherited factory from
>its derived factory. That is it somehow needs to tell the inherited
>factory which class entry to use.
>
>Overriding new could be a solution for php 5.1:
>
>class SQLiteDatabase {
>   // Suppose __new gets executed right after the object
>   // was created and contains the only reference to the
>   // newly created object in its first parameter. And
>   // let it return the instance or NULL. New obviously
>   // needs to be static.
>   // A small side-problem: __new must not be called from
>   // any other place than new.
>   static function __new($instance) {
>     if ($instance->ctorOk()) {
>       return $instance;
>     } else {
>       return NULL;
>     }
>   }
>
>   private function ctorOk() {
>     // just verify the object state once in __new
>   }
>}
>
>Another __new solution would be to let it execute the real
>allocating "new" itself (more like c++ and others) how would
>we differentiate those two news now? Anywhere i suggest the
>code looking something like this:
>
>static function new($file /* params from the new call*/) {
>   $instance = new SQLiteDatabase($file);
>   if ($instance->ctorOk()) {
>     return $instance;
>   } else {
>     return NULL;
>   }
>}
>
>Also the above second new solution has again the inheritance
>problem: Every derived class would have to overwrite __new or
>we need a dynamic allocating new and pass the requested class
>to it:
>
>static function new($class, $file) {
>   $instance = new $class($file);
>   if ($instance->ctorOk()) {
>     return $instance;
>   } else {
>     return NULL;
>   }
>}
>
>Any ideas from you Thies?
>
>best regards
>marcus
>
>Thursday, April 15, 2004, 7:36:46 AM, you wrote:
>
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
>
> > […]

---

## #9167 — Derick Rethans — 2004-04-15T07:59:23+00:00

URL: https://externals.io/message/9161#9167 · In reply to: #9166

> I don't like these ideas. I think it should stay the way it is and not only
> because we're at RC2.
> If Thies doesn't want to deal with this, then he can write constructors
> without logic. It's not that hard for the one in many classes where this
> might be needed.

He's FORCED to do this if extensions use this exception throwing from
constructors. Which is exactly his point here as we're now forcing
people to use this weird exception thing for no reason other than to
satisfy OO purists.

Derick

---

## #9228 — Marcus Boerger — 2004-04-15T20:59:40+00:00

URL: https://externals.io/message/9161#9228 · In reply to: #9167

Hello Derick,

Thursday, April 15, 2004, 9:59:23 AM, you wrote:

> 

> > […]

> He's FORCED to do this if extensions use this exception throwing from
> constructors. Which is exactly his point here as we're now forcing
> people to use this weird exception thing for no reason other than to
> satisfy OO purists.

Hey guys calm down on SQLite. There exceptions are better than handling
errors here or leaving behind an invalid database object. ATM we don't
have an option other than choosing between hell and hell or use exceptions.

And also why do people discurage the use of exceptions that would never use
oo in the first place?

marcus



-- 
Best regards,
 Marcus                            mailto:helly@php.net