Re: exceptions instead of errors
| From: | Jeff Moore | Date: | Tue, 13 May 2003 00:44:18 +0000 |
| Subject: | Re: exceptions instead of errors | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1460@lists.php.net to get a copy of this message | ||
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 ) ) {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.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).