CODEWITHSUNDEEP
c#.netexceptionloggingtry-catch
mark smith
mark smith

Reputation: 20907

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

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?

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

Upvotes: 6

Views: 3979

Answers (6)

supercat
supercat

Reputation: 81247

One common pattern MS seems to like is to have a ComputeSomething() method which returns 'int', and a TryComputingSomething() method which accepts a reference to an integer and returns Boolean. The latter, when successful, stores its computation in the passed-in variable and returns True; if it fails for an "expected" reason, it returns False. Note that unexpected failures in either routine may throw exceptions.

In some cases, it may be helpful to use a different pattern, and have a routine accept a delegate to be invoked in case of trouble. That delegate could either return an exception, or cause the underlying routine to return false, or possibly do other things. Note that at the time the delegate runs, information will be available which would be destroyed before any exception could be caught. For example, if a routine is supposed to read lines from a file and convert characters 20-37 into a Date, it may be helpful to log the entire input line if there's a parsing error. Using a passed-in delegate, one could do that; without such a thing, it would be much harder.

Upvotes: 1

dove
dove

Reputation: 20694

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

Upvotes: 11

Scott Dorman
Scott Dorman

Reputation: 42516

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

Upvotes: 2

Alfred Myers
Alfred Myers

Reputation: 6453

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.

Upvotes: 5

bryanbcook
bryanbcook

Reputation: 18303

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

Upvotes: 4

Chuck Conway
Chuck Conway

Reputation: 16435

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

Upvotes: 1

Related Questions