Comments on: Exceptions, you’re doing it wrong

By: Kadam Ganesh

Kadam Ganesh — Thu, 20 Nov 2008 05:16:47 +0000

Overall a nice article..As suggested by Karl, it is not a very good idea to write
exceptions for each and every error case. What i would like to know is - anybody has any idea about creating a Filter in symfony which will track error mesage and code for each request made. So that errors can be known and dealt with accordingly in the code..

By: Joe Thong

Joe Thong — Thu, 17 Jul 2008 10:14:10 +0000

We have a similar problem a while ago. PropelException was thrown when we are trying to add a duplicate record. I think checking if the duplicate exists before inserting is a bad idea since I don’t want to spend so much SELECT resources just to prevent the 0.05% occurence of a duplicate record in the table. At first I was stumped since PropelException is too generic. Well luckily what Propel did was they actually embedded the PDOException raised by PDO in their PropelException class and could be accessed via the getCause() method. I would then test if this embedded exception is a PDOException and if the PDOException code equals to the 23000 SQLSTATE error code for duplicate records.

The code is:

$e->getCause() instanceof PDOException && 23000 === (int) $e->getCause()->getCode()

By: rpgfan3233

rpgfan3233 — Mon, 16 Jun 2008 17:03:10 +0000

The biggest problem I have with exceptions is when to catch them and provide a friendly message for users v.s. when to let the exception speak for itself v.s. when to catch, repackage and raise the exception again. For example, I was playing with some libxml2/libxslt Python bindings a few weeks ago when I found that I was using try-except far too much because I played with XML schema, XSLT and XML all at once, and I parsed each file to make sure it was well-formed XML before trying to actually use it. Coming from C, I was more worried about specific error messages and return codes than letting things degrade gracefully. After all, letting Python say “parseError” rather than catching the exception is far more efficient, and it doesn’t really harm anything because of the fact that every exception is fatal. How would I know which file failed with a parseError? Debugging, of course. ^_^

Great article overall. Sometimes it is too easy to get happy about using exceptions and classes rather than simple errors and global functions. I once saw some code for a PHP style sheet switcher that was created using a classes… Talk about overkill! :P

By: phloidster

phloidster — Mon, 16 Jun 2008 03:39:41 +0000

Actually, you’re only half right: almost none of these examples should be handled by exceptions at all.

The real abuse of exceptions is using them for domain logic.

There is nothing ‘exceptional’ about not being able to connect to a database, find a row in a table, etc.

These are all situations which fall into the expected logical space of possibilities.

The fact that many frameworks use exceptions incorrectly does not make it acceptable.

This type of exception abuse is part of the downward spiral of ever poorer quality code these days.

Execptions are a mechanism to escape multile levels of a call stack for situations which are so, well, exceptional, that they mostly do not happen.

ALL other use of exceptions is pathlogical and evidence of mental laziness.

By: George M Jempty

George M Jempty — Fri, 23 May 2008 21:43:56 +0000

The reason they all treat an exception from the database layer as a fatal exception, is that they all make the erroneous assumption that “model” and “database” are synonymous.

By: Brian Reich

Brian Reich — Fri, 23 May 2008 18:54:43 +0000

Jon is absolutely right. The base Exception class in PHP takes a message and an error code for a reason, and I think a lot of people forget that. In fact it seems that my all-time favorite framework, the Zend Framework, even forgets this and passes only an error code in many of it’s libraries.

I think subclassing your Exceptions just makes sense. A database connection error might be fatal, but a DB Query error isn’t neccessarily treated the same way. Of course creating a unique Exception subclass for each of the ways that a DB query can fail would just be ridiculous, so at some point it’s up to the programmer to recognize when it’s time to customize a class via parameters rather than subclassing.

What the argument boils down to? Wether you want to handle this way:

catch(DBConnectionException $dbce) {
…
} catch(DBException $dbe) {
…
} catch(Exception $e) {
…
}

Or this way:

catch(Exception $e) {
if($e->getCode() == DBException::CONNECTION_EXCEPTION) {
….
} else {
….
}
}

By: Fredrik Holmström

Fredrik Holmström — Fri, 23 May 2008 18:16:02 +0000

Eli: Nice trick, but all in all I have to say that Python is pretty good at doing “the right thing” with exceptions, KeyError, IterationDone (or whatever the one that ends an iterator is called, always forget), ValueError, etc.

By: Eli Collins

Eli Collins — Fri, 23 May 2008 18:10:52 +0000

Spot on, and I agree that this problem occurs in multiple languages.
Python’s DBAPI uses the exact same generic DatabaseError style.
It annoyed me enough that I wrote a translation layer to catch DatabaseError, run it through some regexps/rules in an external library, and then my apps
can rely on specified exceptions…

sorry this is python not php, but the pattern still works :)

try:
try:
…
except DatabaseError, err:
raise sdutil.adapt_db_error(err)
except sdutil.ConnectionClosedError:
…

found this pattern useful, as it lets the regexp hacks stay in an independantly maintained library.

By: S2

S2 — Fri, 23 May 2008 17:59:06 +0000

> Exceptions should not be created for each and
> every error case, that is just silly.

Why? Every error has it’s exception. That’s how it should be when you write nice clean code. If I throw a GenericException for every error I could possibly have, I will never be able to tell what error was really thrown and what I can do about it. On the other side, if I have an Exception for every error, I can identify every error and handle it the way it should be handled.

By: Fredrik Holmström

Fredrik Holmström — Fri, 23 May 2008 16:30:59 +0000

> First of all, I hope you realise you can package an id with an exception.
> Have you also checked the sfDatabaseException class to see if they
> package the database error code with the exception, my guess is they do.
Yes I’m well aware that you can link an error code with an exception, but no neither symfony (nor any of the other libs I took as example) does this.

> I see how you could make this assumption, but I am afraid you are wrong. > Exceptions should not be created for each and every error case, that is just silly.
I never said that exceptions should be created for every error case, but errors that do stand out and that also make sense to refactor out into their own class should.

> The correct method (as used by Symphony)
Which it isn’t.

I wouldn’t go so far as saying the correct method, but using an error code is also a good way to discriminate exceptions - thought not a method I use personally that much.

I agree with your idea that the code should be used to discriminate different types of errors within the same class of exceptions, but I don’t agree on the fact that all database exceptions should go under one gigantic “DatabaseException” as you suggest.

There is a clear advantage to be able to control the height an exception bubles to through the callstack, which is a lot harder to do with an error code.