Using a code for an exception. Useful?

Question

I am not sure if Exceptions work the same way in each language, but I am using PHP and I was wondering when I'm doing something like this:

if (!$this->connection[0]->query($this->query))
 throw new QueryFailedException($this->connection[0]->error);

Is there a need to supply a code in the second parameter? For example:

if (!$this->connection[0]->query($this->query))
 throw new QueryFailedException($this->connection[0]->error,123);

Now the code is 123... I can't think of a need for this. Is there one? In this case the message contains the query, exception name is QueryFailedException which explains the exception type, the exception itself contains file, line and stack trace, so, I can't think of anything where you could use the code for something useful.

Answer 1

The error code was a feature used when there was no object oriented language. The only thing that could aid you to understand what went wrong was the error code. In an object oriented language, the object IS your error code. Unless, in specific cases, more than one thing can throw the exact same error AND they are treated in different ways, drop it. Also, you would provide much better explanation to whomever is debugging your code if you left a message instead of a meaningless error code, so if you feel like the exception needs more information, fill the Error Message field instead.

Answer 2

The error code is a field that can be used to provide more detailed information. If for example you have two things that can generate the same exception, the code could be used to give more detail.

Answer 3

If you have an "error source" that works on error codes and you "promote" it to exceptions you can include the actual error code in the exception. a) it does no harm and b) maybe you do not want to have an exception class for each single error code that may or may not occur (and virtually no one cares for in a running system).
Let's take the MySQL server errors as an example. You could create one class for each of those codes

class MySQLException_ER_HASHCHK extends MySQLException
class MySQLException_ER_NISAMCHK extends MySQLException
class MySQLException_ER_NO extends MySQLException
class MySQLException_ER_YES extends MySQLException
class MySQLException_ER_CANT_CREATE_FILE extends MySQLException
class MySQLException_ER_CANT_CREATE_TABLE extends MySQLException
class MySQLException_ER_CANT_CREATE_DB extends MySQLException
class MySQLException_ER_DB_CREATE_EXISTS extends MySQLException
class MySQLException_ER_DB_DROP_EXISTS extends MySQLException
....

but in reality ...who cares? Who's really gonna catch them individually? In almost all cases there will only be a catch(MySQLException $mex) in the app's code and maybe, just maybe it's looking for one specific code where it makes little to no difference for the coder whether there are two catch-blocks or an if/switch block. Now you have a lot of "dead" classes and no one -except the parser- gives a damn about them. (on the other hand "everything worth doing is worth overdoing it")
And even if you do provide some granularity I think it makes little sense to go beyond e.g. having one exception class for each SQLState (does that make sense? sqlstate? don't know, just an example)

class MySQLException_HY000 extends MySQLException
class MySQLException_HY001 extends MySQLException
class MySQLException_XA100 extends MySQLException
class MySQLException_XA102 extends MySQLException

And then again you probably want to include the error code - why lose this information even though/even if your code usually doesn't evaluate it?