Re: Exception misinformation

Philippe Jausions wrote:

I was thinking about all this, because it seems like there are not mixed camp about using both errors and exceptions at the same time... I'd be really disappointed if exceptions became the one and only way to handle errors in PEAR/PHP5. There is room and need for both errors and exceptions, as they are conceptually different. Errors are things that are reasonable expectable, while exceptions are with exceptional things.

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, an 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. There is room for cooperation on the warning camp. Imagine that DB::open receives two DSNs, and fails over to the second one: $db = DB::open('someDB','alternative'); $db->execute('someQuery'); You may want to report/log the failure of the first DSN, without interrupting normal flow -- after all, $db is assigned a valid connection -- so this is not a task for exceptions. 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.html Cheers, Sérgio Carvalho

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc