Re: Re: Exception misinformation

On Tue, 06 Jul 2004 22:49:57 +0200, Klaus Guenther <klaus@capitalfocus.org> wrote: > Hans_L wrote: > > > 2) Using exceptions does not mean wrapping every method call in a > > try/catch block. The idea with exceptions is that they allow you to > > group things into logical units -- think of business transactions, or > > Transaction Script pattern. try/catch blocks only need to exist where > > you want them to exist. It allows you to decide what contexts are > > relevant for exceptions. > > > > Here's an example [that I think I've given before]: > > > > function hydrate(ResultSet $rs) { > > try { > > $this->setName($rs->getString(1)); > > $this->setEmail($rs->getString(2)); > > $this->setLoginCount($rs->getInt(3)); > > $this->setPicture($rs->getBlob(4)); > > $this->setLastLogin($rs->getTimestamp(5)); > > $this->setSignature($rs->getString(6)); > > $this->setPassword($rs->getString(7)); > > } catch (SQLException $e) { > > throw new PropelException("Error populating Person object.", $e); > > } > > } > > > So... if an exception is thrown, does the block complete execution? or > does it stop as soon as the exception is thrown? If the former is true, > you need to try for exceptions whenever something important happens. > > For example, in a DB script I have, I need to be able to roll back > anything I've submitted to the DB if something goes wrong. (I'm using > linked tables.) Exceptions would be a huge mess if they allow my script > to first populate all the data before I get notified that I'm in > trouble. This wouldn't make sense to me. However, if the latter is the > way it works, and an exception is simply notifying me that something > minor failed that I don't care about (e.g., if I passed a roman numeral > with illegal characters), then it breaks my whole script until I fix the > input (which I may or may not have control of, esp. if I'm simply > parsing existing data and I don't care if something minor fails). > Exceptions force the developer to group calls into one break/all break > groups. And while for something like a failed DB connection would amply > justify an exception, there are very many errors that don't. > > So the way I see it, try() catch() is a lose/lose situation depending on > what you want to do with it. That's why an error stack is so important > and notices, too. > > Btw, since writing the above I was chatting on IRC and was told by > meebey that when an exception is thrown (and filters down to the level > of the try), execution is halted and catch is envoked. This is bad in > many cases as I've mentioned above. Overuse of exceptions will make PEAR > less than usable. Is that a death knell I hear in the distance? > In this case, you should be using DB Transactions. Do a ROLLBACK in the catch if an error happens to remove all of that info. This is one instance where the exception makes the code easier to write. However, I do see this as a big problem as many (most) applications don't have rollback capabilities. I seem to remember a programming language that had these capabilities...but not many people use it. ;-) See my other response to the thread for more. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--