4

I have seen a lot of exceptions - custom or integrated in the language (PHP) itself that have no differences but their class name.

When extending default exceptions to use within your own code, are there any other things you could implement that are useful besides the more specific exception name that do not violate things like single responsibility?

3

More information about the error. A typical example is an SQL exception where you want to include things like the query that failed, ANSI-SQL error code, vendor-specific error code, the error message from the SQL driver, etc. Other examples: argument name for InvalidArgumentExceptions, HTTP status codes and messages for HttpExceptions, control ID and value for ValidationExceptions, ...

In fact, most exceptions can (and should) carry a bit more information beyond 'something went wrong'.

Even though you should normally avoid presenting this information to the user, it is still enormously helpful when examining logfiles or the like. Imagine you have a log entry that says "SqlException: Column 'usernaem' does not exist. (Query: SELECT * FROM user WHERE username = :usernaem)" instead of just "SqlException"...

  • Just one side comment un-related to the main question.. From security point of view think twice before putting up the actual SQL query statement in the error message. It may not be good idea especially if sufficient care is not taken and the message is propagated up till the end user. – Harish Mar 12 '16 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.