We're discussing the best way to handle errors in calls to a method. 

We have a credit model where we allow users to deduct credits for certain actions. We'd like to make a call to:

```
User.DeductCredits(10);

```

Then the Deduct method will check things like

1. Does the user exist?
2. Is the user active?
3. Does the user have at least 10 credits?

If not, this result should fail.

We're currently writing this just as a class library, but trying to keep it open to convert to a web service in the future. The options we've discussed so far are:

1. Throw an exception when an error occurs.
2. Create a new Result object that would have T has the type of data expected back, and wrapping that with a status code and message.

We didn't like option #1, because then code to call deduct credits would look something like:

```
try
{
   user.DeductCredits(10);
}
catch(InvalidUserException e)
{
}
catch(InactiveUserException e)
{
}
catch(CreditBalanceException e)
{
}

```

Additionally, if we turn this in to a service, we can't force exceptions on the user.

The main reason we didn't like option #2 was that it seemed to be returning more data than what we need. For example:

```
  var address = user.GetMailAddress();

```

Now address has the status code and message, as well as a data property, or value property. So to get the city, you'd have code like:

```
if(!address.HasError)
   state = address.Data.State;

```

as opposed to:

```
state = address.State;

```

So is there a best practice for this type of situation? Is one option really any better than the other?