PHP Pear - RE: [PEAR] PHP5 - Exceptions and the future of PEAR

Author

RE: [PEAR] PHP5 - Exceptions and the future of PEAR_Error

Joe Stump

2004-04-27, 1:21 am

Having been brought up in PHP exclusively, I'm rather na=EFve to the =
whole
idea of exceptions. Could someone explain how throwing exceptions would
rid me of if(!DB::isError($result))?

Again, sorry for being dumb ...

--Joe

> -----Original Message-----
> From: Thorsten Suckow-Homberg [mailto:ts@siteartwork.de]=20
> Sent: Monday, April 26, 2004 12:46 PM
> To: pear-general@lists.php.net
> Subject: [PEAR] PHP5 - Exceptions and the future of PEAR_Error
>=20
>=20
> Hey there,
>=20
> with the RC2 of PHP5 I started migrating my Application from=20
> PHP4 to PHP5.
>=20
> Coming to the point of using exceptions, I am curious of how=20
> PEAR will migrate the PEAR_error-Concept to it - the=20
> thousands of "if(PEAR::isError($yadayada)" will hopefully=20
> become useless now ;)
>=20
> Is there any discussion going on under the devs?
>=20
> Whats the best way to migrate my application regarding the=20
> catch-throw-clause?
>=20
> Should
>=20
> try{
>=20
> }
> catch(PEAR_Exception $exception){
>=20
> }
>=20
> work?
>=20
> Hints please ;)
>=20
> Kind regards
>=20
> Thorsten
>=20
> --=20
> PEAR General Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20

Thorsten Suckow-Homberg

2004-04-27, 1:21 am

>Having been brought up in PHP exclusively, I'm rather naïve to the whole
>idea of exceptions. Could someone explain how throwing exceptions would
>rid me of if(!DB::isError($result))?

Since I started my "programming career" with Java, I think Exceptions is a
great concept of error-handling.

Imagine the following:

In your script is a section that plays around with db-connections and
queries that are all realized over PEAR-Packages. Since you are the kind of
programmer that likes his code to return every single error that occurs
(hey, you are a developer, you should know why your stuff doesn't work ;) ),
you implement it in PHP4 as follows:

(Watch it, the following code is somewhat simplified!)

<?php

$oObject1 = new PEAR_DBClass;

$oObject1->connect("database");

if (PEAR::isError($oObject1)) {
echo "Error occured while connecting to the database
:".$oObject1->getMessage();
die();
}

$resultset = $oObject1->query("SELECT FOO AND SO ON YOU HAVE SOME SQL ERRORS
HERE");

if (PEAR::isError($resultset)) {
echo "Error occured while querying the db:".$resultset->getMessage();
die();
}
..
..
..

?>

I could go on for hours in the same way. Pretty much typing, isn't it? Now
comes the concept of Exceptions, the holy grale of error-handling. Take a
look at this.

<?php

$oObject1 = new PEAR_DBClass;

try {
$oObject1->connect("database");
$resultset = $oObject1->query("SELECT FOO AND SO ON YOU HAVE SOME SQL ERRORS
HERE");
} catch (PEAR_Exception $exception) {
echo "Damn. You got an error here. Here is the message:
".$exception->getMessage();
}

?>

Pretty, huh? Makes the code shorter and more readable IMHO.

Any questions? Just ask! Want to add some correction? Just do it.

Regards

Thorsten

Greg Beaver

2004-04-27, 1:21 am

Thorsten Suckow-Homberg wrote:

>
>
> Since I started my "programming career" with Java, I think Exceptions is a
> great concept of error-handling.

Hi,

PEAR is taking a "wait and see what the problems are" perspective.
Exceptions have a great potential advantage: separating error handling
from the normal flow control.

With PEAR_Error, we have to use PEAR::isError() checks at every function
return, or use a callback, but this method doesn't allow easy jumping
out of a loop for serious errors. Instead, the isError checks slowly
cascade up the hierarchy.

However, exceptions are not a magic pill that will solve all error
handling problems. Exceptions break the normal flow control similar to
a break statement in this PHP4 code

do {
// do something
break;
// nothing here is executed
} while (false);

if you call a method that might throw an exception, but the exception
may be recoverable, you MUST surround the call with a try/catch block or
you run the risk of getting a fatal error or worse, skipping a bunch of
important code when it shunts to the higher level catch.

try {
// do some stuff that throws an exception
$foo->bar()
} catch (Exception $e) {
// handle any recoverable exceptions
}

suddenly, you're forced to handle errors in the normal flow control,
just like PEAR::isError(). The only difference is the kind of punctuation:

$e = $foo->bar();
if (PEAR::isError($e)) {
// handle any recoverable errors and return everything else
}

try {
$foo->bar();
} catch (Exception $e) {
// handle any recoverable exceptions and throw everything else
}

If you are calling a PEAR package that has the try block above, and the
package isn't quite working, it could be very, very difficult to track
down the source of the error if the try/catch block is buried 7 or 8
method calls deep into the source.

Also, if you don't handle an exception, you will get a nasty fatal
error. Try this code:

<?php
// unhandled exception
throw new Exception('oops');
?>

You have to know every exception that might be thrown and handle them.
This can lead to:

try {
$a = new foo('something', 'wrong');
} catch (DB_Exception $e) {
// handle DB Exception
} catch (IO_Exception $e) {
// handle IO exception
} catch (Foo_Exception $e) {
// handle foo exception
} catch (Exception $e) {
// handle any other exceptions
}

Suddenly, you can't read your code because there are thousands of
"catches" all over the place.

For these reasons, I believe exceptions should be used for only extreme
errors - exceptions or faults - and not for trivial things like invalid
parameters passed to functions.

Think of it this way. If you would trigger_error() anything other than
an E_USER_ERROR, an exception is inappropriate.

I've been trying to come up with a solution for a while, and there is
one available in the PEAR package, version 1.3.1. It's a class called
PEAR_ErrorStack. The class allows you to keep all error handling
centralized, but also is flexible enough to work with both PEAR_Error
and Exceptions as needed.

Greg

Sponsored Links