How to name exceptions (PHP)?

Question

I am working on a pretty large project and have read a lot about exception here at stackoverflow and on other websites. The result was, that there is 100% right or wrong. Some throw exceptions for unvalid user inputs, some don't. Some throw exceptions only for runtime errors, some don't...

I personally like the way to throw exceptions even for unvalid user inputs.

Now my problem is that I have for example a user that can comment on a statement of another user (for example his/her favorit music and so on). Every user is only allowed once to comment on it. Now the function which creates a database entry for the comment, checks whether the user has already commented on that statement. If yes, throw an exception. Normally I would say that I name this exception: ExceptionStatementAlreadyCommented but I have many other functions in this project and if I always create such specific exceptions I would end up with about 100 - 200 exceptions.

Does this affect the performance? I autoload the classes needed via the __autoload function, so the actual exception is only loaded when it is needed.

Is it a good way to name exceptions like this? In the past I had trouble with using one exception for different errors because when I catched the exceptions, I sometimes catch exception that I did not want to catch.

Thank you really much for your help!

Best regards,

Freddy

Answer 1

It's good to have a tree of exceptions, extending from the most general to the most specific, for instance, your StatementAlreadyCommentedException (That's how it should be named, with the Exception part at the end) should inherit from InvalidUserInputException, or maybe AlreadyExistsException exception, and those should inherit from something more general, like Exception.

This way, you can catch all exceptions more specific than the one you're searching (should you ever need it). (You can catch Exception, and it would catch every possible exception, you can catch AlreadyExistsException and it would catch any exception extending it.

Answer 2

My feeling is that you are over using exceptions. As referenced by the name, an expection should only be thrown under Exceptional Circumstances.

Exceptions should not be used to control the flow of your application. Users entering bad data or not entering a correct username and password would be considered part of the normal flow of your application, not something exceptional.

You should only throw exceptions in exceptional circumstances that could potentially render the whole or part of the application unusable, for example, not being able to connect to the database.

This way, you will not end up with so many exceptions in the system that requires catching and perhaps rethrowing.

It is a good idea to have different exceptions, for example, I use the RedBean ORM to talk with my database, and it uses these Exceptions:

• RedBean_Exception_Security (when a security exception has occurred).
• RedBean_Exception_SQL (when bad sql syntax or some other issue has occurred).

Being too specific about the exception can lead to a lot of confusion. For example, if I have an exception for missing sql column, bad syntax, missing value, etc, it can become quite unmanagable. But if I have an SQL_Exception, and use that exception for all of the above, then it is much more neater and simplier to manage.

As for performance, having to load a lot of classes (I am assuming they are in external files), can be taxing to the application. This can be partially aleviated by using APC, to cache interpreted PHP code in memory. But this is hard to tell without any profiling.

Answer 3

It does not make sense to create a separate exception class for each possible type of error. The idea is that exception class names should roughly describe the error and each class should have appropriate variables to set so that, together with the exception message, the exact error can be described.

While the current approach is not going to affect your performance (at least the number of exception classes won't), it is probably going to affect your maintainability because it sounds like there's quite a bit of mental overhead that does not actually produce any tangible benefit.

Things will also be much better if you create a well thought-out hierarchy of exceptions instead of producing 200 exception classes that directly extend \Exception.

For example, use something like a RecordAlreadyExistsException exception for all similar cases instead of a ThisTypeOfRecordAlreadyExistsException for each case.