There are several practices, that I found myself using over and over again while working with PHP exceptions. Here they are.
Package/component level exception interface
Create an interface that represents the top level of exceptions hierarchy for your package/component/module. This interface is known as a Marker interface. This approach has several advantages. First, it allows clients of your code to distinguish these component specific exceptions from others. Second, as PHP doesn’t support multiple inheritance, using an interface allows the exceptions to extends from other exceptions. e.g. SPL exceptions.
Here is an example wth usage:
Factory methods to create exceptions
It is quite often, that exception’s message is long and contains some placeholders. Generating this message, especially if you throw it in different places, is not very convenient. In this case a factory method will hide this complexity. Imaging, you are doing something like this:
But instead, it would me much more cleaner to do this:
Extended exceptions with additional details
There are cases, when we need to perform additional actions in catch block. For that we often need to know the details about the original arguments, that caused the exception. For instance, you’re catching a DuplicatedAccountException, and want to know the e-mail, that was passed to a registration service. It might be quite easy, if the call to a service and the catch block are in the same context:
But it is quite common, when you are catching an exception, that is thrown from some deeply nested method, and you don’t have access to the context. In this case, it is helpful to have this information attached to the exception itself.