RE: [PHP-DEV] exceptions instead of errors

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