I have a script that throws exceptions when something goes wrong. However, for the purposes of testing I also want to capture specific points although I'm not sure whether they would be deemed errors or not.

Below is an example:

if ($model->fetchCurrentlyProcessing() > 0) {
    throw new App_Exception_CurrentProcess('There is a currently process running. Stopping process.');

if ($model->fetchQueuedItems() == 0) {
    throw new App_Exception_NothingInQueue('Nothing in queue. Stopping process.');

In my tests I want to mock the response from these $model methods and detect which exception was thrown, and whether it was the expected exception or not. By throwing exceptions in these cases I can identify exactly at what point the script stopped. But I'm not sure if this is the correct usage of Exceptions as these possible aren't errors to be precise, as in nothing went wrong.

3 Answers 3


An exception signifies an "exceptional situation" due to which a piece of code stops working. This may be an error, but it may also be any other situation which is exceptional and it prevents the code from doing its job.

So, both of your examples appear very good cases of exceptions to me: your code is supposed to do a certain job, and it cannot do it, so it throws an exception.

What it boils down to is how you define an "exceptional situation", and by extension, how you describe what your code does. If you call your code "process items in queue", then not finding any items in the queue is an exceptional situation. If you call your code "process queued items, if any", then not finding any items in the queue is not an exceptional situation.

  • 2
    What it boils down to is how you define an "exceptional situation". Indeed, and that is why I think you are wrong to suggest that nothing in the queue is an exceptional circumstance. Both of the OP's examples are unexceptional IMO. In fact they are really quite normal circumstances when running jobs from a queue and therefore I'd argue throwing exceptions for either case is a misuse of exceptions.
    – David Arno
    Commented Jan 8, 2016 at 15:28

While I agree with most of what Mike said, I would say your way is never the right way to use exceptions. You are basically replacing something like "if queue is empty, return" with an exception. That is, you are using exceptions as a way of flow control to implement your basic algorithm and that is not good. Exceptions handle exceptional situations and while those are not necessarily errors, they typically are and should at least indicate a situation that renders continuing pointless. Finding out your queue is empty or there is still some task running so you have to wait a bit longer is hardly a ruin of plans. And since you will be doing this routinely, it will impact performance because exceptions aren't cheap, which is not an issue in case of an abort, but this is not an abort, it is just a loop.


An exception should be thrown whenever a function cannot return a value or a method is unable to meet it's post-condition. This can happen because the inputs are out of range or because of some external condition. It doesn't matter how often the exception is thrown.

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.