Everything

php

Home » Project » Newsgroups » php.internals » exceptions instead of errors »

exceptions instead of errors

php.internals

(Marcus Börger)

23 years ago

The following patch:
http://marcus-boerger.de/php/ext/exception.diff

allows in a short, straight forward and easy way to suppress errors and
optionally throw exceptions instead. This is supposed to be automated
by the try opcode (but that is another discussion).

The problem:
During development of SQLite i found the problem that i had to inform
the user about an error inside a constructor. This can only be done by
throwing an exception. (Repeat: this cannot be done otherwise). The
main problem herin is that we have many little utility functions that may
raise errors (like safe mode and such).

This means we had to rewrite the whole api, pass information around
or find a generic solution.

Ok here goes:

First i fixed the "ignore repeated errors" feature. Then i added some control
information to struct _php_core_globals:
error_handling_t  error_handling;
zend_class_entry *exception_class;

error_handling can be one of EH_NORMAL, EH_SUPPRESS and EH_THROW
- EH_NORMAL is the normal way errors are handled
- EH_SUPPRESS means the error is stored but not shown (suppressed even)
- EH_THROW throws an exception of type PG(exception_class) or the default
exception class if PG(exception_class) is NULL.

To manually change the mode or class there is the following function:
PHPAPI void php_set_error_handling(error_handling_t
error_handling, zend_class_entry *exception_class TSRMLS_DC)

The mechanism itself is located in the function php_error_cb which is called
during all error calls. So every error, warning or notice is catched. BUT of
corse the mechanism doesn't work with E_ERROR, E_PARSE or such. These
are real errors and are errors even after the patch.

The reason the exception class can be set is to easily support exception
inheritance
for the lazy programmers.

The reason to support EH_SUPPRESS is for more sophisticated problems...

When the mechanismn throws an error it automatically sets these exception
properties:
- message        the error message
- file           the filename
- line           the line number in the file

Further more i suggest we add the severity to the default exception.

Some help of the engine would be good:
- automatically set EH_THROW mode at "try"
- automatically set EH_NORMAL mode at "catch" (first outmost catch)

If noone objects i will commit this on monday evening.

Unfortunately there is a memory leak in the exception handling itself but
that is another story...and will hopefully soon be fixed by somebody else.

Anybody interested can try the patch with my patched SQLite:
http://marcus-boerger.de/html/php/ext/sqlite/
and especially look into test sqlite_oo_020.phpt

regards
marcus

--
------------------->>> mailto:mail@marcus-boerger.de <<<------------------
"We are animals among animals, all children of matter,
save that we are the more disarmed. But since, unlike animals,
we know that we must die, let us prepare for that moment
by enjoying the life that has been given us by chance and for chance."
Umberto Eco, The island of the day before
--------------------->>> http://marcus-boerger.de <<<---------------------

(Marcus Börger)

23 years ago

At 02:53 04.05.2003, Marcus Börger wrote:

>[...]
>Anybody interested can try the patch with my patched SQLite:

Ha, to late here already
http://marcus-boerger.de/php/ext/sqlite/

Andi Gutmans

23 years ago

At 02:53 AM 5/4/2003 +0200, Marcus Börger wrote:

>Some help of the engine would be good:
>- automatically set EH_THROW mode at "try"
>- automatically set EH_NORMAL mode at "catch" (first outmost catch)

Huh? I think it's definitely not obvious that I'd want these to happen
automatically. Actually I personally wouldn't, because I'd prefer PHP to
continue the way it works and only use exceptions in user-land.

>If noone objects i will commit this on monday evening.

Please don't before this is discussed. We have discussed this kind of thing
quite a few times and our opinion was that error handling in PHP shouldn't
be changed. We wouldn't want some configuration switch to change how the
scripts work nor is it a good idea if the same script behaves differently
according to one switch.
Anyway, we can discuss this again but definitely I don't think we should
jump the gun with commits in this area until people really think of the
whole picture. We have a large user base out there and we still want all of
the user-base to "talk" in the same language.
I won't really be around for the next two weeks so maybe it's best to wait
or in the least make sure Zeev takes part in this discussion.
Thanks,
Andi

P.S. -BTW, what does SQLite do?

Derick Rethans

23 years ago

On Sat, 3 May 2003, Andi Gutmans wrote:

> At 02:53 AM 5/4/2003 +0200, Marcus Börger wrote:
> >Some help of the engine would be good:
> >- automatically set EH_THROW mode at "try"
> >- automatically set EH_NORMAL mode at "catch" (first outmost catch)
>
> Huh? I think it's definitely not obvious that I'd want these to happen
> automatically. Actually I personally wouldn't, because I'd prefer PHP to
> continue the way it works and only use exceptions in user-land.

I don't see a problem with auto-detecting if exceptions should be trown
when somebody enters a try { } statement?

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

George Schlossnagle

23 years ago

On Sunday, May 4, 2003, at 11:30  AM, Derick Rethans wrote:

> On Sat, 3 May 2003, Andi Gutmans wrote:
>
>> At 02:53 AM 5/4/2003 +0200, Marcus Börger wrote:
>>> Some help of the engine would be good:
>>> - automatically set EH_THROW mode at "try"
>>> - automatically set EH_NORMAL mode at "catch" (first outmost catch)
>>
>> Huh? I think it's definitely not obvious that I'd want these to happen
>> automatically. Actually I personally wouldn't, because I'd prefer PHP
>> to
>> continue the way it works and only use exceptions in user-land.
>
> I don't see a problem with auto-detecting if exceptions should be trown
> when somebody enters a try { } statement?

This is exactly why I never understood not wanting to throw exceptions
instead of E_ERRORs.  If you aren't 'using exceptions' (i.e. writing
code that uses try{} catch{}), you will still get the same behavior (a
fatal termination of the script).  If you are programming with
exceptions you will get the functionality you almost certainly desire.

George

Wez Furlong

23 years ago

On Sat, 3 May 2003, Andi Gutmans wrote:

> P.S. -BTW, what does SQLite do?

It's an embedded database that features a very complete implementation
of SQL, including triggers and transactions.  The data is stored in a
single file that is portable across machine architectures.

It is very fast in read-only applications, outperforming postgres by 2-3
times the number of requests per second in some simple tests performed
by Edin.

However, its performance for high concurrency updates will be quite
poor, as it locks the whole database when making changes.

--Wez.

See:

http://www.sqlite.org
Home Page

http://pear.php.net/package-info.php?pacid=193
PECL extension, featuring bundled sqlite library:
("pear install SQLite" will build and install everything you need)

PS: The simple read-only tests had the following results, if anyone
is interested:

Requests per second:
sqlite:     28.01
mysql:      19.81
postgres:   10.52
DB2:        8.76

(Marcus Börger)

23 years ago

At 17:30 04.05.2003, Derick Rethans wrote:

>On Sat, 3 May 2003, Andi Gutmans wrote:
>
> > At 02:53 AM 5/4/2003 +0200, Marcus Börger wrote:
> > >Some help of the engine would be good:
> > >- automatically set EH_THROW mode at "try"
> > >- automatically set EH_NORMAL mode at "catch" (first outmost catch)
> >
> > Huh? I think it's definitely not obvious that I'd want these to happen
> > automatically. Actually I personally wouldn't, because I'd prefer PHP to
> > continue the way it works and only use exceptions in user-land.
>
>I don't see a problem with auto-detecting if exceptions should be trown
>when somebody enters a try { } statement?

As already said this can easily be done. If thats our consensus then it's
only adding some three lines in the engine.

marcus

(Marcus Börger)

23 years ago

At 04:32 04.05.2003, Andi Gutmans wrote:

>At 02:53 AM 5/4/2003 +0200, Marcus Börger wrote:
>>Some help of the engine would be good:
>>- automatically set EH_THROW mode at "try"
>>- automatically set EH_NORMAL mode at "catch" (first outmost catch)
>
>Huh? I think it's definitely not obvious that I'd want these to happen
>automatically. Actually I personally wouldn't, because I'd prefer PHP to
>continue the way it works and only use exceptions in user-land.
>
>>If noone objects i will commit this on monday evening.
>
>Please don't before this is discussed. We have discussed this kind of
>thing quite a few times and our opinion was that error handling in PHP
>shouldn't be changed. We wouldn't want some configuration switch to change
>how the scripts work nor is it a good idea if the same script behaves
>differently according to one switch.

There will surely no switch, that would be the stuiest thing we cold do.

>Anyway, we can discuss this again but definitely I don't think we should
>jump the gun with commits in this area until people really think of the
>whole picture. We have a large user base out there and we still want all
>of the user-base to "talk" in the same language.

Large user base? Who the hell uses ze2 or php5 widely out there?
The patch is intended for the new php5/ze2 oo features and will not change
any php4 features or its behavior.
It simply makes it possible to throw exceptions in ctors (and for that
there is now other solution).

Everything else the patch offers can surely be discussed: automation with
try/catch and so on.

What i like would be:

1) procedural (aka php4) no change (aka simply errors as of now)
2) oo (aka new php5/ze2 features) always throw exceptions instead of errors.

for example:

let's assume we have an extension "example" consisting of a function
"example_test", a namespace "example"
containing a function "factory" and a class "whatever" with a "whatelse":

example_test(); //-> normal operation or error mechanism

$obj = example::factory(); // -> object creation or exception
$obj = new example::whatever(); // -> object creation or exception

$obj->whatelse(); // -> normal operation or exception

WHY: becasue this only changes new things we don't have yet and it is easy
to learn
and deal with: "procedural = errors, oo = exceptions".

>I won't really be around for the next two weeks so maybe it's best to wait
>or in the least make sure Zeev takes part in this discussion.

Then i hope you can answer now :-)

>Thanks,
>Andi
>
>P.S. -BTW, what does SQLite do?

Just as Wez said. And you may take a look at my patches and tests for it on
the url i gave. Because this
extension lets you test exceptions with ctors and the factory() function.

regards
marcus

l0t3k

23 years ago

along the lines of this discussion, i had posted a (ignored) message
concerning the behaviour of zend_parse_parameters. my point was/is that
there should be an extra parameter which determines whether a regular PHP
error or exception is raised. otherwise its useless to use in an OO
extension (particularly in the case of constructors). if we adopt this
approach, i think we'd also need an IllegalArgumentException or somesuch.

l0t3k

"Marcus Börger" <marcus.boerger@t-online.de> wrote in message
news:5.1.0.14.2.20030504021938.09452980@mailbox.rwth-aachen.de...

l0t3k

23 years ago

along the lines of this discussion, i had posted a (ignored) message
concerning the behaviour of zend_parse_parameters. my point was/is that
there should be an extra parameter which determines whether a regular PHP
error or exception is raised. otherwise its useless to use in an OO
extension (particularly in the case of constructors). if we adopt this
approach, i think we'd also need an IllegalArgumentException or somesuch.

l0t3k

"Marcus Börger" <marcus.boerger@t-online.de> wrote in message
news:5.1.0.14.2.20030504021938.09452980@mailbox.rwth-aachen.de...

(Marcus Börger)

23 years ago

At 20:17 04.05.2003, l0t3k wrote:

>along the lines of this discussion, i had posted a (ignored) message
>concerning the behaviour of zend_parse_parameters. my point was/is that
>there should be an extra parameter which determines whether a regular PHP
>error or exception is raised. otherwise its useless to use in an OO
>extension (particularly in the case of constructors). if we adopt this
>approach, i think we'd also need an IllegalArgumentException or somesuch.

My patch opens the doors to such behavior :-)

regards
marcus

Sterling Hughes

23 years ago

Just a note that I'd really like to see this.  One of the great things
about exceptions will be:

try {
$m = mysql_connect("localhost", "user", "pass");
$sth = mysql_query("select bar from foo", $m);
while ($row = mysql_fetch_array($sth)) {
echo $row[0];
}
mysql_close($m);
} catch (exception $e) {
echo $e->getMessage();
}

This allows you to remove all the nasty if ($conn) could, and move your
error handling into a singular place. I *really* would like this for
internal functions.  We could also make a new type of exception
"internalexception," which a user has to specifically catch.  This way
unless you explictly specify that you want to catch an
internalexception, it will default to just outputting an error message.

-Sterling

On Sat, 2003-05-03 at 20:53, Marcus Börger wrote:

> The following patch:
> http://marcus-boerger.de/php/ext/exception.diff
>
> allows in a short, straight forward and easy way to suppress errors and
> optionally throw exceptions instead. This is supposed to be automated
> by the try opcode (but that is another discussion).
>
> The problem:
> During development of SQLite i found the problem that i had to inform
> the user about an error inside a constructor. This can only be done by
> throwing an exception. (Repeat: this cannot be done otherwise). The
> main problem herin is that we have many little utility functions that may
> raise errors (like safe mode and such).
>
> This means we had to rewrite the whole api, pass information around
> or find a generic solution.
>
> Ok here goes:
>
> First i fixed the "ignore repeated errors" feature. Then i added some control
> information to struct _php_core_globals:
>          error_handling_t  error_handling;
>          zend_class_entry *exception_class;
>
> error_handling can be one of EH_NORMAL, EH_SUPPRESS and EH_THROW
> - EH_NORMAL is the normal way errors are handled
> - EH_SUPPRESS means the error is stored but not shown (suppressed even)
> - EH_THROW throws an exception of type PG(exception_class) or the default
>    exception class if PG(exception_class) is NULL.
>
> To manually change the mode or class there is the following function:
>          PHPAPI void php_set_error_handling(error_handling_t
> error_handling, zend_class_entry *exception_class TSRMLS_DC)
>
> The mechanism itself is located in the function php_error_cb which is called
> during all error calls. So every error, warning or notice is catched. BUT of
> corse the mechanism doesn't work with E_ERROR, E_PARSE or such. These
> are real errors and are errors even after the patch.
>
> The reason the exception class can be set is to easily support exception
> inheritance
> for the lazy programmers.
>
> The reason to support EH_SUPPRESS is for more sophisticated problems...
>
> When the mechanismn throws an error it automatically sets these exception
> properties:
> - message        the error message
> - file           the filename
> - line           the line number in the file
>
> Further more i suggest we add the severity to the default exception.
>
> Some help of the engine would be good:
> - automatically set EH_THROW mode at "try"
> - automatically set EH_NORMAL mode at "catch" (first outmost catch)
>
> If noone objects i will commit this on monday evening.
>
> Unfortunately there is a memory leak in the exception handling itself but
> that is another story...and will hopefully soon be fixed by somebody else.
>
> Anybody interested can try the patch with my patched SQLite:
> http://marcus-boerger.de/html/php/ext/sqlite/
> and especially look into test sqlite_oo_020.phpt
>
> regards
> marcus
>
>
> --
> ------------------->>> mailto:mail@marcus-boerger.de <<<------------------
> "We are animals among animals, all children of matter,
> save that we are the more disarmed. But since, unlike animals,
> we know that we must die, let us prepare for that moment
> by enjoying the life that has been given us by chance and for chance."
>                                 Umberto Eco, The island of the day before
> --------------------->>> http://marcus-boerger.de <<<---------------------

--
"The computer programmer is a creator of universes for which he
alone is responsible. Universes of virtually unlimited complexity
can be created in the form of computer programs."
- Joseph Weizenbaum

Daniel Lorch

23 years ago

hi,

> Just a note that I'd really like to see this.  One of the great things
> about exceptions will be:
>
> try {
>   $m = mysql_connect("localhost", "user", "pass");
>   $sth = mysql_query("select bar from foo", $m);
>   while ($row = mysql_fetch_array($sth)) {
>     echo $row[0];
>   }
>   mysql_close($m);
> } catch (exception $e) {
>   echo $e->getMessage();
> }
>
> This allows you to remove all the nasty if ($conn) could, and move your
> error handling into a singular place. [..]

Read more here:

http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html

Basically try/catch-statements allow you to keep the main code block short
and readable because the error handling code is moved somewhere else. Would
be nice seeing this in PHP.

-daniel

Terence

23 years ago

some questions

Daniel Lorch wrote:

> hi,
>
>
>>Just a note that I'd really like to see this.  One of the great things
>>about exceptions will be:
>>
>>try {
>>  $m = mysql_connect("localhost", "user", "pass");
>>  $sth = mysql_query("select bar from foo", $m);
>>  while ($row = mysql_fetch_array($sth)) {
>>    echo $row[0];
>>  }
>>  mysql_close($m);
>>} catch (exception $e) {

Is "exception" class built in? if so, extendable by users?
if not, how does getMessage() know where to find the error - especially
if this error is produced by an extension.

>>  echo $e->getMessage();
>>}
>>
>>This allows you to remove all the nasty if ($conn) could, and move your
>>error handling into a singular place. [..]
>
>
> Read more here:
>
>   http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html
>

And reading the article, one can see that it relys on types to bubble up
and be cought correctly.

(Marcus Börger)

23 years ago

>
>Is "exception" class built in? if so, extendable by users?

There is a builtin exception class that can be inherited at C-level api.
For now it is also inheritable inside PHP scripts but we may have
two different types for internal and userland exceptions respectively
or add another getter method to query that information.

>if not, how does getMessage() know where to find the error - especially if
>this error is produced by an extension.

There is a dynamic property $message that can be set inside the
constructor. Additional there are $code/getcode(), $file/getfile()
and $line/getline(). However these properties are dynamically created
upon instantiating when an internal exception is thrown or the
exception::exception() constructor is called. So when inheriting
the exception class simply ensure the base class constructor will
be called.

In the current implementation the above are not defined when inheriting
the exception base class. But expect this to change so that these
properties are declared in the base class as protected.
marcus

(Marcus Börger)

23 years ago

At 12:59 05.05.2003, Daniel Lorch wrote:

>Read more here:
>
>
>http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html
>
>Basically try/catch-statements allow you to keep the main code block short
>and readable because the error handling code is moved somewhere else. Would
>be nice seeing this in PHP.

Then basically you did the main error with exceptions. They are exceptions.
So the normal error handling should still be done by rceiving error codes or
reacting on the return values of functions. However it is possible to move all
error handling into a catch block...

There is only one thing that cannot be solved other than with excetions
and that is error situations in constructors.

regards
marcus

Derick Rethans

23 years ago

On Sun, 4 May 2003, Sterling Hughes wrote:

> Just a note that I'd really like to see this.  One of the great things
> about exceptions will be:
>
> try {
>   $m = mysql_connect("localhost", "user", "pass");
>   $sth = mysql_query("select bar from foo", $m);
>   while ($row = mysql_fetch_array($sth)) {
>     echo $row[0];
>   }
>   mysql_close($m);
> } catch (exception $e) {
>   echo $e->getMessage();
> }
>
> This allows you to remove all the nasty if ($conn) could, and move your
> error handling into a singular place. I *really* would like this for
> internal functions.  We could also make a new type of exception
> "internalexception," which a user has to specifically catch.  This way
> unless you explictly specify that you want to catch an
> internalexception, it will default to just outputting an error message.

Sounds like a great idea to me!

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

(Marcus Börger)

23 years ago

At 16:23 11.05.2003, Derick Rethans wrote:

>On Sun, 4 May 2003, Sterling Hughes wrote:
>
> > Just a note that I'd really like to see this.  One of the great things
> > about exceptions will be:
> >
> > try {
> >   $m = mysql_connect("localhost", "user", "pass");
> >   $sth = mysql_query("select bar from foo", $m);
> >   while ($row = mysql_fetch_array($sth)) {
> >     echo $row[0];
> >   }
> >   mysql_close($m);
> > } catch (exception $e) {
> >   echo $e->getMessage();
> > }
> >
> > This allows you to remove all the nasty if ($conn) could, and move your
> > error handling into a singular place. I *really* would like this for
> > internal functions.  We could also make a new type of exception
> > "internalexception," which a user has to specifically catch.  This way
> > unless you explictly specify that you want to catch an
> > internalexception, it will default to just outputting an error message.
>
>Sounds like a great idea to me!

Yes to me, too! I'll change my error2exception thingie to reflect your idea.

marcus

Zeev Suraski

23 years ago

At 17:37 11/05/2003, Marcus Börger wrote:

>At 16:23 11.05.2003, Derick Rethans wrote:
>>On Sun, 4 May 2003, Sterling Hughes wrote:
>>
>> > Just a note that I'd really like to see this.  One of the great things
>> > about exceptions will be:
>>
>> > try {
>> >   $m = mysql_connect("localhost", "user", "pass");
>> >   $sth = mysql_query("select bar from foo", $m);
>> >   while ($row = mysql_fetch_array($sth)) {
>> >     echo $row[0];
>> >   }
>> >   mysql_close($m);
>> > } catch (exception $e) {
>> >   echo $e->getMessage();
>> > }
>> >
>> > This allows you to remove all the nasty if ($conn) could, and move your
>> > error handling into a singular place. I *really* would like this for
>> > internal functions.  We could also make a new type of exception
>> > "internalexception," which a user has to specifically catch.  This way
>> > unless you explictly specify that you want to catch an
>> > internalexception, it will default to just outputting an error message.
>>
>>Sounds like a great idea to me!
>
>
>Yes to me, too! I'll change my error2exception thingie to reflect your idea.

What do you have in mind?

Sterling's description was actually one of the original reasons for
introducing exceptions into PHP, at least from my point of view.  But it's
not very clear how exactly it can actually be implemented, because what
we're dealing with here are warnings, not errors.  There are probably ways
to address this, but it's not trivial and should be discussed.

Zeev

(Marcus Börger)

23 years ago

At 17:00 11.05.2003, Zeev Suraski wrote:

>At 17:37 11/05/2003, Marcus Börger wrote:
>>Yes to me, too! I'll change my error2exception thingie to reflect your idea.
>
>What do you have in mind?
>
>Sterling's description was actually one of the original reasons for
>introducing exceptions into PHP, at least from my point of view.  But it's
>not very clear how exactly it can actually be implemented, because what
>we're dealing with here are warnings, not errors.  There are probably ways
>to address this, but it's not trivial and should be discussed.

I'll implement a derived exception class as described and make my
error2exception stuff use that exception
as default instead of using the excetopn base class as adefault.

marcus

Theo Spears

23 years ago

On Sunday 04 May 2003 20:48, Sterling Hughes wrote:

> Just a note that I'd really like to see this.  One of the great things
> about exceptions will be:
>
> try {
>   $m = mysql_connect("localhost", "user", "pass");
>   $sth = mysql_query("select bar from foo", $m);
>   while ($row = mysql_fetch_array($sth)) {
>     echo $row[0];
>   }
>   mysql_close($m);
> } catch (exception $e) {
>   echo $e->getMessage();
> }
>
> This allows you to remove all the nasty if ($conn) could, and move your
> error handling into a singular place. I *really* would like this for
> internal functions.  We could also make a new type of exception
> "internalexception," which a user has to specifically catch.  This way
> unless you explictly specify that you want to catch an
> internalexception, it will default to just outputting an error message.
>

Although this approach would certainly simplify handling errors it seems to me
it would give everyone big problems when it comes to predicting the control
flow of their programs. For example

function db_connect ( $db_name ) {
$link = mysql_connect();
if ( ! mysql_select_db( $db_name, $link ) ) {
mysql_select_db ( BACKUP_DB_NAME, $link );
}
}

now, depending on whether you do

try {
db_connect ( 'foo' );
} catch (exception e) {
}

or just

db_connect ( 'foo' );

The function will behave differently. Even if all new PHP5 code uses
exceptions there is a lot of code which doesn't, and so the principles of
information hiding say you would have to make sure any code which calls a
function in a separate module has to make sure that function isn't inside a
try{}catch{} block, and the only functions in the same module which are
inside try{}catch{} blocks that catch internal exceptions don't call any
functions in external modules.

Personally I would prefer a system similar to the @ notation which suppresses
error messages, possibly make %function() or similar cause the function to
raise an exception. (The engine could handle this by silently dropping all
exceptions from internal functions that weren't called with the relevant
prefix).

Just my £0.02

Theo Spears

Jeff Moore

23 years ago

On Sunday, May 11, 2003, at 11:40  AM, Theo Spears wrote:

> Although this approach would certainly simplify handling errors it
> seems to me
> it would give everyone big problems when it comes to predicting the
> control
> flow of their programs. For example
>
> function db_connect ( $db_name ) {
>   $link = mysql_connect();
>   if ( ! mysql_select_db( $db_name, $link ) ) {
>     mysql_select_db ( BACKUP_DB_NAME, $link );
>   }
> }
>
> now, depending on whether you do
>
> try {
>   db_connect ( 'foo' );
> } catch (exception e) {
> }
>
> or just
>
> db_connect ( 'foo' );
>
> The function will behave differently. Even if all new PHP5 code uses
> exceptions there is a lot of code which doesn't, and so the principles
> of
> information hiding say you would have to make sure any code which
> calls a
> function in a separate module has to make sure that function isn't
> inside a
> try{}catch{} block, and the only functions in the same module which are
> inside try{}catch{} blocks that catch internal exceptions don't call
> any
> functions in external modules.
>
> Personally I would prefer a system similar to the @ notation which
> suppresses
> error messages, possibly make %function() or similar cause the
> function to
> raise an exception. (The engine could handle this by silently dropping
> all
> exceptions from internal functions that weren't called with the
> relevant
> prefix).

Sadly, the problem is that the default behavior you want for modern
programming is to raise the exception from the built in functions.  The
default behavior you want for compatibility is to not raise the
exception.  If I read this correctly, I think the % operator is
backwards from what I would want.

My preference would be not to add an operator, but to make this an
error_reporting option.

Such as E_RAISE_EXCEPTIONS.

Then you could turn it on when you wanted it and turn it off when you
wanted to call old code.

I think for backward compatibility purposes, you would not want to put
it in E_ALL.

Thus, people using exceptions would typically put a

error_reporting(E_ALL | E_RAISE_EXCEPTIONS);

at the top of their code.

Then, if you call older code that relies on a different behavior, it is
your responsibility to turn automatic exceptions off.

$rl = error_reporting(error_reporting() & ~E_RAISE_EXCEPTIONS );
db_connect ( 'foo' );
error_reporting($rl);

Only if you mix exception aware and non-exception aware code are you
saddled with the burden of extra code.

Note that with this approach, I would think that

trigger_error()

should raise an exception if E_RAISE_EXCEPTION was enabled.

(Marcus Börger)

23 years ago

At 17:40 11.05.2003, Theo Spears wrote:

>On Sunday 04 May 2003 20:48, Sterling Hughes wrote:
> > Just a note that I'd really like to see this.  One of the great things
> > about exceptions will be:
> >
> > try {
> >   $m = mysql_connect("localhost", "user", "pass");
> >   $sth = mysql_query("select bar from foo", $m);
> >   while ($row = mysql_fetch_array($sth)) {
> >     echo $row[0];
> >   }
> >   mysql_close($m);
> > } catch (exception $e) {
> >   echo $e->getMessage();
> > }
> >
> > This allows you to remove all the nasty if ($conn) could, and move your
> > error handling into a singular place. I *really* would like this for
> > internal functions.  We could also make a new type of exception
> > "internalexception," which a user has to specifically catch.  This way
> > unless you explictly specify that you want to catch an
> > internalexception, it will default to just outputting an error message.
> >
>Although this approach would certainly simplify handling errors it seems
>to me
>it would give everyone big problems when it comes to predicting the control
>flow of their programs. For example
>
>function db_connect ( $db_name ) {
>   $link = mysql_connect();
>   if ( ! mysql_select_db( $db_name, $link ) ) {
>     mysql_select_db ( BACKUP_DB_NAME, $link );
>   }
>}
>
>now, depending on whether you do
>
>try {
>   db_connect ( 'foo' );
>} catch (exception e) {
>}
>
>or just
>
>db_connect ( 'foo' );
>
>The function will behave differently. Even if all new PHP5 code uses
>exceptions there is a lot of code which doesn't, and so the principles of
>information hiding say you would have to make sure any code which calls a
>function in a separate module has to make sure that function isn't inside a
>try{}catch{} block, and the only functions in the same module which are
>inside try{}catch{} blocks that catch internal exceptions don't call any
>functions in external modules.
>
>Personally I would prefer a system similar to the @ notation which suppresses
>error messages, possibly make %function() or similar cause the function to
>raise an exception. (The engine could handle this by silently dropping all
>exceptions from internal functions that weren't called with the relevant
>prefix).

The rule "try/catch = exception" would be easy enough to understand.
Changing all code to use exceptions would also work since the bahaviour
would fall back to the normal one if you missed to define a try/catch block.

marcus

Steven Brown

23 years ago

> -----Original Message-----
> From: Marcus Börger [mailto:marcus.boerger@t-online.de]
> Sent: Sunday, May 11, 2003 9:53 AM
> To: Theo Spears
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] exceptions instead of errors
>
>
> At 17:40 11.05.2003, Theo Spears wrote:
> >On Sunday 04 May 2003 20:48, Sterling Hughes wrote:
> > > Just a note that I'd really like to see this.  One of the great
> > > things about exceptions will be:
> > >
> > > try {
> > >   $m = mysql_connect("localhost", "user", "pass");
> > >   $sth = mysql_query("select bar from foo", $m);
> > >   while ($row = mysql_fetch_array($sth)) {
> > >     echo $row[0];
> > >   }
> > >   mysql_close($m);
> > > } catch (exception $e) {
> > >   echo $e->getMessage();
> > > }
> > >
> > > This allows you to remove all the nasty if ($conn) could,
> and move
> > > your error handling into a singular place. I *really* would like
> > > this for internal functions.  We could also make a new type of
> > > exception "internalexception," which a user has to specifically
> > > catch.  This way unless you explictly specify that you
> want to catch
> > > an internalexception, it will default to just outputting an error
> > > message.
> > >
> >Although this approach would certainly simplify handling errors it
> >seems
> >to me
> >it would give everyone big problems when it comes to
> predicting the control
> >flow of their programs. For example
> >
> >function db_connect ( $db_name ) {
> >   $link = mysql_connect();
> >   if ( ! mysql_select_db( $db_name, $link ) ) {
> >     mysql_select_db ( BACKUP_DB_NAME, $link );
> >   }
> >}
> >
> >now, depending on whether you do
> >
> >try {
> >   db_connect ( 'foo' );
> >} catch (exception e) {
> >}
> >
> >or just
> >
> >db_connect ( 'foo' );
> >
> >The function will behave differently. Even if all new PHP5 code uses
> >exceptions there is a lot of code which doesn't, and so the
> principles
> >of information hiding say you would have to make sure any code which
> >calls a function in a separate module has to make sure that function
> >isn't inside a try{}catch{} block, and the only functions in
> the same
> >module which are inside try{}catch{} blocks that catch internal
> >exceptions don't call any functions in external modules.
> >
> >Personally I would prefer a system similar to the @ notation which
> >suppresses error messages, possibly make %function() or
> similar cause
> >the function to raise an exception. (The engine could handle this by
> >silently dropping all exceptions from internal functions
> that weren't
> >called with the relevant prefix).
>
>
> The rule "try/catch = exception" would be easy enough to
> understand. Changing all code to use exceptions would also
> work since the bahaviour would fall back to the normal one if
> you missed to define a try/catch block.

The problem will be that catch-all exception handling will cause all
code your project uses to act differently, whether it was designed to
expect exceptions thrown from internal functions or not.  Same deal with
nested uses of internal functions in pre-exception-aware code like in
Theo's example.  In those cases, the error handling code will get
skipped completely, which definitely wasn't intended by whoever wrote
the code.  It's probably best from a compatibility standpoint to have to
indicate at point of use (like with that '%' prefix) that the
surrounding code understands exceptions.

(Marcus Börger)

23 years ago

At 04:07 12.05.2003, Steven Brown wrote:

>The problem will be that catch-all exception handling will cause all
>code your project uses to act differently, whether it was designed to
>expect exceptions thrown from internal functions or not.  Same deal with
>nested uses of internal functions in pre-exception-aware code like in
>Theo's example.  In those cases, the error handling code will get
>skipped completely, which definitely wasn't intended by whoever wrote
>the code.  It's probably best from a compatibility standpoint to have to
>indicate at point of use (like with that '%' prefix) that the
>surrounding code understands exceptions.

"try" is new so i cannot imagine any BC problem when try results in
errors being converted into exceptions.

marcus

Steven Brown

23 years ago

> -----Original Message-----
> From: Marcus Borger [mailto:marcus.boerger@t-online.de]
> Sent: Monday, May 12, 2003 10:11 AM
> To: Steven Brown
> Cc: 'Theo Spears'; internals@lists.php.net
> Subject: RE: [PHP-DEV] exceptions instead of errors
>
>
> At 04:07 12.05.2003, Steven Brown wrote:
>
> >The problem will be that catch-all exception handling will cause all
> >code your project uses to act differently, whether it was designed to
> >expect exceptions thrown from internal functions or not.  Same deal with
> >nested uses of internal functions in pre-exception-aware code like in
> >Theo's example.  In those cases, the error handling code will get
> >skipped completely, which definitely wasn't intended by whoever wrote
> >the code.  It's probably best from a compatibility standpoint to have to
> >indicate at point of use (like with that '%' prefix) that the
> >surrounding code understands exceptions.
>
> "try" is new so i cannot imagine any BC problem when try results in
> errors being converted into exceptions.

Maybe I'm just missing something, but if the decision to throw from a
function that previously didn't use exceptions for error handling is based
on if it's being used while in a try {} block, if you wrap your new php file
with try {} but also make use of an old library, you've just changed the
internal behavior of the library code, making it a BC issue.  The PHP
library you're calling for example never gets to handle errors as it was
designed to, as every error unwinds the calls rather than returning null or
whatever and being handled internally by the library.  The only way to
safely make use of older libraries in this case would be to not use mix them
with exception-aware code, which would be a barrier to entry for people
wanting to gradually migrate to php5.

(Marcus Börger)

23 years ago

At 01:52 13.05.2003, Steven Brown wrote:

>Maybe I'm just missing something, but if the decision to throw from a
>function that previously didn't use exceptions for error handling is based
>on if it's being used while in a try {} block, if you wrap your new php file
>with try {} but also make use of an old library, you've just changed the
>internal behavior of the library code, making it a BC issue.

SURE, but that's the point: if you're trying to mix old and new behaviour then
you can't expect that everything works as expected. If noone here is allowed
to make any progress then we simply stop all development and are fine and
have some fun in the sun.

And if BC is everything and you want your old libs then simply noone forces
you to use PHP5.

marcus

Steven Brown

23 years ago

> -----Original Message-----
> From: Marcus Borger [mailto:marcus.boerger@t-online.de]
> Sent: Monday, May 12, 2003 4:56 PM
> To: Steven Brown
> Cc: 'Theo Spears'; internals@lists.php.net
> Subject: RE: [PHP-DEV] exceptions instead of errors
>
>
> At 01:52 13.05.2003, Steven Brown wrote:
> >Maybe I'm just missing something, but if the decision to throw from a
> >function that previously didn't use exceptions for error
> handling is based
> >on if it's being used while in a try {} block, if you wrap your
> new php file
> >with try {} but also make use of an old library, you've just changed the
> >internal behavior of the library code, making it a BC issue.
>
> SURE, but that's the point: if you're trying to mix old and new
> behaviour then
> you can't expect that everything works as expected. If noone here
> is allowed
> to make any progress then we simply stop all development and are fine and
> have some fun in the sun.
>
> And if BC is everything and you want your old libs then simply
> noone forces
> you to use PHP5.

Why should we have to rewrite all our libraries for php5 just to use them?
That seems rather heavy-handed.  What's needed is a way to recognize code
written before PHP threw exceptions on internals so PHP can just simply do
the right thing.  The '%' prefix on internals idea was one way of doing
that.  I'd much rather a solution along those lines exist than have to
rewrite all my code.

John Coggeshall

23 years ago

I don't know if anyone has discussed this in any length or not, but what
about adding a new error type (E_EXCEPTION)... I'm 100% for the idea of
having PHP throw exceptions internally, however there are E_ERRORs that
are indeed fatal in their context and shouldn't be caught. If this
different error level existed, it could be treated like an E_ERROR if
not within a try{} block, however will still preserve the meaning of the
error code and give maintainers an opportunity to change their
extensions to support exceptions as appropriate.

John

--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

George Schlossnagle

23 years ago

What is the point of having a new error type?  How does that differ
semantically from just throwing an exception?

The only way I could see something like this working is

exceptions=E_ALL|~E_NOTICE

which would throw an exception on all non-notice errors.  I think this
would be a Bad Idea though, as it is much less intuitive than throwing
exceptions on E_ERROR in a try block or when set_exception_handler has
set a final exception handler.

George

On Monday, May 12, 2003, at 08:16  PM, John Coggeshall wrote:

John Coggeshall

23 years ago

On Mon, 2003-05-12 at 21:41, George Schlossnagle wrote:

> What is the point of having a new error type?  How does that differ
> semantically from just throwing an exception?

I discussed this with Shane @ PHP-CON.. It was in the context of
throwing exceptions for all E_ERRORs internally, and then having a
default catch which trigger the standard E_ERROR. The idea was that
errors could be caught then without breaking BC. However, Shane rightly
pointed out that the issue with that solution was that although some
E_ERRORs could be considered "recoverable" and an exception would make
sense, there are some E_ERRORs which simply should cause execution to
halt.

Since the idea of figuring out which E_ERRORs were catchable and which
ones were not was unreasonable, the thought was that the creation of a
separate error type that was functionality identical to E_ERROR could be
created. This way internally new code could throw exceptions, and it
would provide a means for maintainers to roll-into the idea of having
exceptions in established extensions without causing any shake-up.

> The only way I could see something like this working is
>
> exceptions=E_ALL|~E_NOTICE
>
> which would throw an exception on all non-notice errors.  I think this
> would be a Bad Idea though, as it is much less intuitive than throwing
> exceptions on E_ERROR in a try block or when set_exception_handler has
> set a final exception handler.

Again, the problem with that solution is the concept that some E_ERRORs
really shouldn't be thrown as exceptions, while others it'd be useful.

John

--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

George Schlossnagle

23 years ago

On Monday, May 12, 2003, at 10:12  PM, John Coggeshall wrote:

> However, Shane rightly
> pointed out that the issue with that solution was that although some
> E_ERRORs could be considered "recoverable" and an exception would make
> sense, there are some E_ERRORs which simply should cause execution to
> halt.

These should be E_CORE_ERRORs most likely and not be thrown.  This
error type already exists and is used throughout the engine.

>
> Since the idea of figuring out which E_ERRORs were catchable and which
> ones were not was unreasonable, the thought was that the creation of a
> separate error type that was functionality identical to E_ERROR could
> be
> created. This way internally new code could throw exceptions, and it
> would provide a means for maintainers to roll-into the idea of having
> exceptions in established extensions without causing any shake-up.

The vast majority of E_ERRORs are recoverable.  There's no BC issue
either, do to the arguments posted elsewhere by me, Marcus, Sterling
and others.  It's really transparent from a BC issue.

(Marcus Börger)

23 years ago

At 04:12 13.05.2003, John Coggeshall wrote:

>On Mon, 2003-05-12 at 21:41, George Schlossnagle wrote:
> > What is the point of having a new error type?  How does that differ
> > semantically from just throwing an exception?
>
>I discussed this with Shane @ PHP-CON.. It was in the context of
>throwing exceptions for all E_ERRORs internally, and then having a
>default catch which trigger the standard E_ERROR. The idea was that
>errors could be caught then without breaking BC. However, Shane rightly
>pointed out that the issue with that solution was that although some
>E_ERRORs could be considered "recoverable" and an exception would make
>sense, there are some E_ERRORs which simply should cause execution to
>halt.
>
>Since the idea of figuring out which E_ERRORs were catchable and which
>ones were not was unreasonable, the thought was that the creation of a
>separate error type that was functionality identical to E_ERROR could be
>created. This way internally new code could throw exceptions, and it
>would provide a means for maintainers to roll-into the idea of having
>exceptions in established extensions without causing any shake-up.

NO exceptions for E_CORE_<whatever> and E_PARSE.
and there is really no reason for another error type. the problem lies in the
handling of all those errors spit out by our handy c-level utility functions
such like open basedir checks and all. And repeated once again: We have
two choices (erm three we can f**k up the language and its oo capabilities)
first rewrite the whole c-level api to know whether or not an exception should
be thrown or not or seconf find an automatic solution as my proposal.

>
> > The only way I could see something like this working is
> >
> > exceptions=E_ALL|~E_NOTICE
> >
> > which would throw an exception on all non-notice errors.  I think this
> > would be a Bad Idea though, as it is much less intuitive than throwing
> > exceptions on E_ERROR in a try block or when set_exception_handler has
> > set a final exception handler.

AND surely no more ini settings.

>Again, the problem with that solution is the concept that some E_ERRORs
>really shouldn't be thrown as exceptions, while others it'd be useful.

Yes we must fix those places were E_ERROR was used in a wrong way
and use another error level instead.

regards
marcus

Zeev Suraski

23 years ago

At 21:22 13/05/2003, Marcus Börger wrote:

>>Again, the problem with that solution is the concept that some E_ERRORs
>>really shouldn't be thrown as exceptions, while others it'd be useful.
>
>
>Yes we must fix those places were E_ERROR was used in a wrong way
>and use another error level instead.

It may be semantical, but these are not places where E_ERROR is being used
in a wrong way.  E_ERROR, today, is being used for both cases where
semantically we shouldn't be continuing our execution, and places where
we're in an unstable state and cannot continue our execution.  If we want
to differentiate between these two cases, we need a new error level.

I must have missed your proposal, can you send a link?

Zeev

(Marcus Börger)

23 years ago

At 20:29 13.05.2003, Zeev Suraski wrote:

>At 21:22 13/05/2003, Marcus Börger wrote:
>>>Again, the problem with that solution is the concept that some E_ERRORs
>>>really shouldn't be thrown as exceptions, while others it'd be useful.
>>
>>
>>Yes we must fix those places were E_ERROR was used in a wrong way
>>and use another error level instead.
>
>It may be semantical, but these are not places where E_ERROR is being used
>in a wrong way.  E_ERROR, today, is being used for both cases where
>semantically we shouldn't be continuing our execution, and places where
>we're in an unstable state and cannot continue our execution.  If we want
>to differentiate between these two cases, we need a new error level.

If this is true then we could simply keep out E_ERROR.

>I must have missed your proposal, can you send a link?

Hm i have removed the patch already....maybe an archieve contains it still.

marcus

George Schlossnagle

23 years ago

On Monday, May 12, 2003, at 08:08  PM, Steven Brown wrote:

>> And if BC is everything and you want your old libs then simply
>> noone forces
>> you to use PHP5.
>
> Why should we have to rewrite all our libraries for php5 just to use
> them?
> That seems rather heavy-handed.  What's needed is a way to recognize
> code
> written before PHP threw exceptions on internals so PHP can just
> simply do
> the right thing.  The '%' prefix on internals idea was one way of doing
> that.  I'd much rather a solution along those lines exist than have to
> rewrite all my code.

Why would you have to rewrite all your code?  If you don't catch the
error, it will be fatal (just as before).  If you are in a try block
when you call the library generating an error, you have the option of

a) rethrowing the error
b) not catching the exception type thrown (I'm for a new default type
SystemException extends Exception for this btw)
c) handling the exception

a and b give you the behavior you had in php4, c allows you to possibly
recover.

At any rate, since try{} catch{} did not exist when you wrote your
library, you wouldn't have to rewrite any old code, just be aware of
the new semantics when you write new code that uses your old libraries.

George

Steven Brown

23 years ago

> -----Original Message-----
> From: George Schlossnagle [mailto:george@omniti.com]
> Sent: Monday, May 12, 2003 6:46 PM
> To: Steven Brown
> Cc: marcus.boerger@post.rwth-aachen.de; 'Theo Spears';
> internals@lists.php.net
> Subject: Re: [PHP-DEV] exceptions instead of errors
>
>
>
> On Monday, May 12, 2003, at 08:08  PM, Steven Brown wrote:
> >> And if BC is everything and you want your old libs then
> simply noone
> >> forces you to use PHP5.
> >
> > Why should we have to rewrite all our libraries for php5 just to use
> > them?
> > That seems rather heavy-handed.  What's needed is a way to
> recognize
> > code
> > written before PHP threw exceptions on internals so PHP can just
> > simply do
> > the right thing.  The '%' prefix on internals idea was one
> way of doing
> > that.  I'd much rather a solution along those lines exist
> than have to
> > rewrite all my code.
>
> Why would you have to rewrite all your code?  If you don't catch the
> error, it will be fatal (just as before).

If it's fatal, there's no issue.  What I'm worried about is the
suggestion made earlier that non-fatal errors, like mysql_connect
returning false, would throw instead of return false if the activation
has a try {} of some kind along its path, or a special internalexception
variant of catch().  It'd basically be dynamic scoping the error
handling behavior, which would add danger to using old libraries in new
code.  E.g., exception-aware code uses old exception-unaware code
somewhere inside a try {} and the error handling would all get skipped
as the exception unwinds all the way out of the old code.

I'm all for non-fatal errors in internal functions throwing exceptions,
it's the right way to go, but want to see it solved in a way that
doesn't needlessly add danger to mixing in older code.

(Marcus Börger)

23 years ago

>If it's fatal, there's no issue.  What I'm worried about is the
>suggestion made earlier that non-fatal errors,

Then use @mysql_connect(...)

>E.g., exception-aware code uses old exception-unaware code
>somewhere inside a try {} and the error handling would all get skipped
>as the exception unwinds all the way out of the old code.

It is the sense of exceptions that you do not need other error handling.

>I'm all for non-fatal errors in internal functions throwing exceptions,
>it's the right way to go, but want to see it solved in a way that
>doesn't needlessly add danger to mixing in older code.

Good to hear :-)

marcus

Derick Rethans

23 years ago

On Mon, 12 May 2003, Steven Brown wrote:

> Why should we have to rewrite all our libraries for php5 just to use them?
> That seems rather heavy-handed.  What's needed is a way to recognize code
> written before PHP threw exceptions on internals so PHP can just simply do
> the right thing.  The '%' prefix on internals idea was one way of doing
> that.  I'd much rather a solution along those lines exist than have to
> rewrite all my code.

No more magic prefixes, we're not perl.

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Steven Brown

23 years ago

> -----Original Message-----
> From: Derick Rethans [mailto:derick@php.net]
> Sent: Tuesday, May 13, 2003 12:47 AM
> To: Steven Brown
> Cc: PHP Developers Mailing List
> Subject: RE: [PHP-DEV] exceptions instead of errors
>
>
> On Mon, 12 May 2003, Steven Brown wrote:
>
> > Why should we have to rewrite all our libraries for php5
> just to use
> > them? That seems rather heavy-handed.  What's needed is a way to
> > recognize code written before PHP threw exceptions on
> internals so PHP
> > can just simply do the right thing.  The '%' prefix on
> internals idea
> > was one way of doing that.  I'd much rather a solution along those
> > lines exist than have to rewrite all my code.
>
> No more magic prefixes, we're not perl.

Then pick some other way you like, there're surely several ways to reach
the same ends.  It's just an example of the kind of thing that would
solve that problem without creating new problems.  Personally, I'd say
use new function names for exception-throwing versions of old functions,
or stick exception-throwing wrappers in PEAR.

Alan Knowles

23 years ago

A very difficult problem with very little in the way of clean solutions..
my only thought was:

mysql::connect() would thrown an exception
mysql_connect() would emit an error..

basically all 'object methods - static or dynamic' would be expected to
throw errors, where as functions would just emit errors.
so you could implement object wrappers for key 'exception em
It's far from a complete solution. (downside is the extra documentaiton
overhead of this..)

Regards
Alan

>Then pick some other way you like, there're surely several ways to reach
>the same ends.  It's just an example of the kind of thing that would
>solve that problem without creating new problems.  Personally, I'd say
>use new function names for exception-throwing versions of old functions,
>or stick exception-throwing wrappers in PEAR.
>
>
>
>

--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com

Zeev Suraski

23 years ago

When I told Marcus that this whole business is far from being trivial,
that's exactly what I meant.  And that's why we haven't added the
exceptions-for-errors at the same time we implemented exceptions, and why
Andi said a few days ago that it shouldn't be introduced without further
discussion.

In my opinion, exceptions-for-errors at the language (ini) level should be
removed.  Instead, we should leave that entirely to userspace.  People will
be able to write their own error handler, and throw an exception if they
wish.  That gives them more granularity (they can selectively throw an
exception).  It's going to be especially useful if we go back to one of our
old ideas, which is assigning each error with its own unique idea, and
would be even more useful if we give each extension its own designated
range of error codes.

If we go in that direction, it would probably make sense to introduce a new
error level in between E_ERROR and E_WARNING, that is fatal, but catchable
by the error callback.

Zeev

At 12:05 13/05/2003, Alan Knowles wrote:

George Schlossnagle

23 years ago

The issue though is that almost none of the E_ERRORs in the engine are
actually really fatal.  I agree that the issue of things which are
currently E_WARNINGs is complex (I personally think they should be
handled by wrapper implementations that throw exceptions or vice-versa,
but I think that is an issue for a different discussion), but the
E_ERROR behavior change is completely clean and does not jeopardize BC
at all.

George


On Tuesday, May 13, 2003, at 08:52  AM, Zeev Suraski wrote:

Zeev Suraski

23 years ago

At 16:35 13/05/2003, George Schlossnagle wrote:

>The issue though is that almost none of the E_ERRORs in the engine are
>actually really fatal.

I haven't counted, but there certainly are many that are fatal.

>   I agree that the issue of things which are currently E_WARNINGs is
> complex (I personally think they should be handled by wrapper
> implementations that throw exceptions or vice-versa, but I think that is
> an issue for a different discussion), but the E_ERROR behavior change is
> completely clean and does not jeopardize BC at all.

You mean making E_ERROR's throw exceptions?  It jeopardizes stability.  We
can only do it if we introduce the new error level and selectively change
existing E_ERRORs to that error level, iff they don't leave the engine (or
other parts of the infrastructure) in an unstable state.  We also have to
change the default extension handler to be slightly smarter and emit an
error message identical to the ones that we emit today, with no traces of
"exception" in there - people who don't ask for exceptions shouldn't bump
into them.

Zeev

(Marcus Börger)

23 years ago

At 11:05 13.05.2003, Alan Knowles wrote:

>A very difficult problem with very little in the way of clean solutions..
>my only thought was:
>
>mysql::connect() would thrown an exception
>mysql_connect() would emit an error..
>
>basically all 'object methods - static or dynamic' would be expected to
>throw errors, where as functions would just emit errors.
>so you could implement object wrappers for key 'exception em
>It's far from a complete solution. (downside is the extra documentaiton
>overhead of this..)

Besides the fact that i like try == exception more this would be easy
to implement, too. A little bit problematic might be static namespace
functions.

regards
marcus

(Marcus Börger)

23 years ago

At 14:52 13.05.2003, Zeev Suraski wrote:

>[...]
>It's going to be especially useful if we go back to one of our old ideas,
>[...]

As i made up a patch for that noone was interested and the discussion on
that issue
turned out that there are far to many problems. Anybody not remembering
please read
the archieves.

regards
marcus