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?

3 Answers 3


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.

  • Thanks for the insightful answer. We are developing an e-commerce website. The upper layer which calls on my wrapper functions is still not decided, so I was trying to anticipate the use cases. Could you suggest any articles / computer science topics / or design patterns relevant to this?
    – zacurry
    Jun 25, 2016 at 10:27
  • @zacurry I am not sure if you can even call this a design pattern, rather than using a feature a language offers. When you're layering an application, you should build the layers in a way that fulfils your needs in the best way.
    – Andy
    Jun 25, 2016 at 13:08

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...


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.

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.