Using bool (return Type) to handle exceptions or pass exception to client?

Question

I am trying to find out the best way of handling exceptions, I have a number of layers to my application and started to use a return type of BOOL i.e. if it fails then return False and if it succeeds return True..

This works great in methods like SaveMyRecord(somerecord); as i am passing in values and don't require anything returned so i can use the return type of bool to indicate if it succeeds or not.

But then it got me thinking that things like GetMyRecord() actually returns type of IQueryable hence i can't use a bool to tell me if it failed or not.

The thing is i am handle alot of my errors where they happen with try and catch and hence don't want the client to receive an exception.

Maybe there is a better way, i then got thinking about using OUT parameters BUT this means i need to change the signature of all methods and add aditional params..

Maybe i should be passing the exception back to the CLIENT and handling it there?

I am a little lost,

Is there some standards or any docs to adivse best practices?

Answer 1

You should start reading Design Guidelines for Exceptions

Then, depending on your scenario, you should take other considerations into account such as Exception Shielding.

For instance: If you are using web services (ASMX or WCF) as a back-end, you may want to take a look at Improving Web Services Security and read the parts concerning exception handling.

Answer 2

Bubble up the exception to the CLIENT and handle it there. Definitely pass it in full detail all the way up. Most best practices almost entirely agree on this, always finally handle on the perimeter, in this case the CLIENT, though in other cases that could be a web service.

Only catch if you want to log it, add more info to it or try and recover from a particular exception. In each case you will will either throw a new exception with the original as the inner or simply 'throw' the original as is, and as pointed in comments don't 'throw ex'

This question is a near duplicate and you'd find lots of existing very well answered questions on SO. I answered a similar one only yesterday

Answer 3

This a great question!

Don't code for exception. For the most part pretend they never happened. I worry about exception in two places: Displaying error feedback to the user and resource management (i.e. closing an open file when a exception is throw).

Answer 4

If a method can't do it's job, it should throw an exception. Never return an exception as a result.

Answer 5

The approach that is recommended and considered a best practice is to use exceptions. You can (and should) read the Framework Design Guidelines (2nd Ed.), which has guidelines for exceptions and the try-parse pattern.

There are a few problems with using return codes (either numeric or boolean), the two biggest being:

• Easily overlooked/ignored by programmers.
• Can't be used in all situations. What happens if your constructor fails? It's not possible for you to return a value explicitly from a constructor.

As for when to handle exceptions, you should only handle them when you can do something meaningful about the exception. The problem with always handling exceptions so the client never sees them is that you can end up handling an exception that you shouldn't have and cause more problems later (like actually loosing data).