I've seen that it's possible to extend the default Exception class in PHP, enabling one to throw an IncorrectParameterTypeException exception, or a ValueOutOfRangeException exception (maybe these are bad examples of custom exceptions... I'm still learning).

But I'm just wondering, why would I want to do this? I would include "Parameter must be a string" (or whatever the error was) as the Exception's message anyway, so it's not like it's offering any new information.

Is it just a code readability thing, or am I missing something? I am just starting to learn about custom Exception classes, so I'm assuming the latter.

2 Answers 2


Its useful in that you can then add extra information that the base exception class does not hold.

So you can create a NetworkException class and that would contain information about the socket error code and/or the destination connection address or whatever you liked. Callers can catch this and present better information for diagnosis of the error.

However you now start to get into an analysis issue - why bother writing all that info and a new exception class when chances are, the caller who catches your exception will just write all that custom info into a string and dump it into log file or display it as 'detailed information' to the user - you might as well write it to the base classes string member and have done with it, save everyone a load of hassle.

But, if you did have a custom exception class, the client can catch only those that they care about and let others continue up the call stack for someone else to handle - eg the caller might catch a NetworkException when the user clicks connect, but let an OutOfMemoryException continue and .. well, usually crash the client.

So its a bit of one of those areas where you have to think hard about the design, and often no answer you come up with is the "right" one, any are just as good. (for example, I have a tool written in C#, and there are lots and lots of Microsoft exception classes that I might catch... although I do catch a few special exception classes for certain circumstances, I still tend to catch all of them and print out the base class message anyway (or worse - the innerexception message, don't go there). This is a admin tool so writing out every exception message is what I need, and every Microsoft exception contains a message with the details I want to log so I really don't care about the exception class!

so its up to you, though I would advise against creating a huge inheritance hierarchy of every possible error, that way lies a lot of maintenance and documentation trouble.


It allows you to wrap exceptions in a more generic exception.

Let's say that you are developing a library to manage products. In order to support as many different environments as possible, you make your data access system flexible and allow the users of your library to store data in a MySQL database, an XML file and a JSON file and 'plug in' the right storage.

The code that works with the library might need to trap the exceptions that occur in your library to provide meaningful feedback. For example, it might want to 'fall back' to some local storage when the actual storage is not available. In order to do this it would need to trap every kind of exception that has to do with the storage, but might not want to trap something like a NullPointerException or ObjectIsInAnInvalidStateToBePersistedException.

Hence, you create a generic DataStorageException. Each implementation catches their own exceptions at appropriate places and wraps that exception in the generic DataStorageException. The MySQL implementation might trap a CannotConnectToServerException or InvalidUserException while the XML implementation might want to catch the DataFileNotFoundException.

The consumer of your library simply needs to catch the DataStorageExceptions and does not need to know about the implementation.

It allows you to require additional information.

You can define exceptions that require information to be passed. For example, an ArgumentOutOfRangeException could be forced by the constructor to provide the actual range that is valid. The class could then construct the message for the exception dynamically based on these values.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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