Design-Question: Using ReturnValue or Throwing Exception
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
You could return an instance of a structure instead of a double. This structure could contain any number of fields, which would provide you with unlimited information.
struct TransactionResult
{
double amount;
bool Success;
int ErrorCode;
}The difficult we do right away... ...the impossible takes slightly longer.
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
Frygreen wrote:
b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
Why? If you want to communicate "what" went wrong you'll probably need a reference to a resource-text that is translated, and provide the variables.
Frygreen wrote:
a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard
c) exceptions aren't there to model business cases, but for handling unexpected results in code. Yours isn't.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
The real question is "Is a withdrawal allowed if it results in a negative balance?" and that isn't necessarily a function of that method - for example, my current account has a "permitted overdraft" permanently attached so by balance can genuinely and acceptably go negative, up to a preset limit. So having a Withdraw method that automatically refuses a transaction if it would result in a negative balance may be against the business logic. In addition, accounts often have "pending transactions" which may not be reflected in the balance but which could change the "approve / reject" decision. Think about how you are doing this: you should probably divide the responsibilities up into three sections - Presentation (user interface), Business logic, and Data handling - and a withdrawal request would come from the Presentation to the Business for approval, and on then be committed to Data storage by the Business logic if approved, or rejected to the Presentation if not. Certainly, I don't think an exception would be right - normal processing shouldn't use exceptions for flow control.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
Depends on the requirements. I personally try not to throw exceptions unless it makes sense to do so. You don't have to return additional info. In this case, overdrafts might be allowed (if they are, you can also specify an overdraft limit, but I leave that as an exercise for you).
public decimal MakeWithdraw(ref decimal balance, decimal amount, bool allowOverdraft=false)
{
decimal widthdrawn = (amount <= balance) ? amount : ((allowOverdraft) ? amount : balance);
balance -= withdrawn;
return widthdrawn;
}BTW, using decimal instead of double is a good idea because math performed on doubles is not as accurate as math performed on decimals.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
If this is the basis of an "accounting" system, then "transactions" never "fail". And you don't "withdraw", you post a "debit" (increase in asset accounts / decrease in a liability account; etc.); or "credit". And each "amount" "posted" to one account, is offset by an entry to another account (i.e. credit cash - debit accounts payable). At the end of the day, the "reports" indicate who owes what, etc. (A "mini" blockchain if you will; i.e. "ledger")
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I have an Account class, which has a function
double WithDraw(double amountToWithdraw) {
...some code here....
}If the balance of this account is <= 0, then what should I do? ==> throw an exception (which one?) ==> return 0.0 with some additional information? (in which way?) I guess: a) throwing an exception could be wrong, because this scenario is not "exceptional", but standard b) returning some additional information requires to return a object with additional attributes or a reference to an object in the parameterlist. Seems to be crazy too.
Based on all of your feedback and some additional search I have the following solution for me I will return a Transaction-Object
struct TransactionResult {
double amountReturned;
EnumTransactionResult eReturn;
}Some more info: - I have no complicated scenarios as "Pending Transactions" - Of course: I can overdraw the account upto an allowed value, which can be less than zero - This fully fulfills my use-case Thank you for your input. My question is fully answered
