exceptions instead of errors View as Markdown

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 <<<

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

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/

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