RE: [PHP-DEV] exceptions instead of errors

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