Re: Exception misinformation
| From: | Lukas Smith | Date: | Thu, 08 Jul 2004 08:06:32 +0000 |
| Subject: | Re: Exception misinformation | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31738@lists.php.net to get a copy of this message | ||
Sergio Carvalho wrote:
Philippe Jausions wrote: I absolutely disagree. Exceptions are the best way to handle errors, and leave no space for return codes. An error is any kind of condition that prohibits the execution of further code. In your DB example, anUhm, there are tons of errors that dont prohibit further execution of code. But yes as I was saying exceptions are perfect for fatal errors (and a few other cases as well like iterators, failures in constructors - then again you shouldnt design your constructors so that they can fail).
exception is the way to go. Consider this pseudo-code: $db = DB::open('someDB'); $db->execute('someQuery'); The first line *must* return a DB connection, or else the second one won't work. If by any chance, the open fails, an exception must be thrown, to avoid execution of the second line.I also think that opening a database connection should throw an exception.
I'll launch you a challenge. Java is a mature language, that has had exceptions since its inception. Go through the Java standard library: http://java.sun.com/j2se/1.4.2/docs/api/ and find usage of return codes for errors. For reference, the equivalent to DB::connect is here: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Driver.htmlas Philippe pointed out Java as severe limitations that make it a less than ideal rolemodel for us: namely its a strongly typed language. regards, Lukas