Return values for a delete function in php

Question

I am writing a wrapper function for database calls, and I am confused about the best way to handle the error cases.

The function has only one argument, the id of the object to be deleted.

I've handled two error cases :
1)If the object is not found i return false.
2)If the object is found but delete fails due to some exception I catch it and return false.

Should I use different return values for the above conditions? Is there a particular design pattern I can refer to in this situation?

Answer 1

The answer to your question is: it depends. What you are currently doing is called exception suppression, that is calling a method which may throw and returning false when it indeed happens. Is it a good practice? That is difficult to answer without knowing exactly what you want from the method where you are suppressing the exception.

I personally have completely given up on suppressing exceptions just for the sake of returning false when an exception is thrown and build my code knowing that, but sometimes having a method which is exception safe might be a good idea.

I have found out having a method throw different kind of exceptions is good when you want to process each given exception type differently, such as one means internal server error while the other may simply indicate a user is not authorized to perform certain action. Then the api of the method are not only its parameters and return values but also the exceptions the method throws.

With error suppression and returning false always, you have no option to distinguish the internal error of the method, because it is all hidden behind one return value, false. That does not necessarily mean that it is not a valid design.

All in all, if all you want is to know whether an operation was successful or not, suppressing an exception and returning a bool flag might be a good idea, if you however want the system to react differently to different exceptions, you are much better off with the method throwing, you consuming the exceptions and dispatching events as reactions to them.

Answer 2

I'd take a look at what would be useful to whatever calls your delete method.

At the moment, client code calling this method will see a false condition when the item isn't there to delete, or is not able to delete...

How should the client code react? Is it important that your client code does something in either case?

Without knowing what the application is for, you could actually return true in the case of nothing to delete, if the result should be the same.

You might also want your client code reacting to different exceptions thrown inside the delete...

Answer 3

The real question here is "what is the consequence of failure?"

If you delete something and it's not there, who cares? You wanted it gone anyway.

If you want to insert data and it fails, what can you possibly do? Nothing, really.

How, or even if you communicate errors largely depends on the fault tolerance of that transaction. Deleting something that doesn't exist is not a reason to throw an exception. Returning true or false is only useful if there is a tangible thing a user can do afterwords.

Failure to insert or update data is a reason to throw an exception, because the computer cannot possibly recover from that and you should have caught the problem with a validation.

Now if you can't connect to a database to begin with then you should always throw an exception, even when deleting something.