 |
|
SledgeHammer01 wrote: Goes back to my first point, once you start doing custom exceptions, its easy to get overzealous and make everything exception
That seems like what's going on here.
The problem is that if you want to return some kind of message to the UI, then the message has to be defined in the DAL or BL, rather than in the UI where it belongs. Using the custom exception tells the UI "Hey, this condition occurred. You decide how to tell the user", rather than "Hey, this condition occurred and here's what to tell the user".
If it's not broken, fix it until it is
|
|
|
|
|
Is the user really going to be able to do anything about the error? Most of the time probably not if they are not technical. The .Net framework throws custom exceptions so you might want to be consistent with that. Personally I try to show the user as few errors as possible because they'll just think the software is buggy. Better to try to handle common errors yourself silently and log the ones you can't.
|
|
|
|
|
I think this is a great question to throw (  ) out in the community and I am interested in seeing the responses. I am in favor of throwing exceptions on errors and when the code encounters an unexpected situation. Vague, I know. I would not want to make a more detailed statement because it depends on what is considered unexpected in any given function, library or application.
In an application handling charges to credit cards, I do not think it is unexpected that an amount can exceed the available credit limit, so I would be against categorizing that as an exception. It seems to me that if you go down that road, you end up defining the program behavior through the use of exceptions.
Here is a link to what I will normally follow.
http://msdn.microsoft.com/en-us/library/ms173163.aspx[^]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
That sounds OK to me, but that still doesn't seem enough like an Exception, and a boolean wouldn't give enough information, a good old enumerated value might be good.
public enum TransactionStatus
{
Pending
,
Applied
,
Rejected
,
NoSuchAccount
,
InsufficientFunds
...
}
|
|
|
|
|
{ true, false, EFileNoteFound }?
Needless to say, I'd recommend using the exceptions; yes, there's a performance-penalty, but it's hardly noticeable. Unless it's in a tight loop, you won't notice it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The problem with this is that, one, Exceptions are a little expensive to throw, so if you end up throwing a lot of them, well, it adds up.
Two, as the name suggests, is what you're finding "exceptional"? No, it's not. What you're doing is making a determination of an account status as part of a normal business process. You're chosing two different paths to return the two possible states of an account. THe account can either have sufficient credit, or not.
What you should be doing is not relying on exceptions to determine the state of a business object. The business object should be telling you its state. If you have to wrap or include a state object in your transaction object, fine.
Exceptions should be used to transmit information outside of your normal business process, such as if a transaction fails to commit because of a database failure.
|
|
|
|
|
Dave Kreskowiak wrote: the state of a business object
Who said anything about business objects? 
|
|
|
|
|
Dave Kreskowiak wrote: The problem with this is that, one, Exceptions are a little expensive to throw
This is a bit of a myth.[^] if you run tests with the debugger on you get poor performance, without debugging it is OK.
Otherwise, I agree. We use the exceptions as business logic at work and I don't like it: We've 100s of exception classes (and a deep hierarchy) to handle cases that often should be state within a business object. Not only is there this exception-bloat but it makes stuff harder to trace: I have to work up through the potential call stack to see where something is handled. Not only that we rely on the exception being caught somewhere (if not the user gets an error screen for normal business logic), instead of a more traceable return result (or object state).
I can see where the "exception" camp comes from, but I think they are wrong.
“Education is not the piling on of learning, information, data, facts, skills, or abilities - that's training or instruction - but is rather making visible what is hidden as a seed”
“One of the greatest problems of our time is that many are schooled but few are educated”
Sir Thomas More (1478 – 1535)
|
|
|
|
|
Keith Barrow wrote: This
is a bit of a myth.[^] if you run tests with the debugger on you get poor
performance, without debugging it is OK.
Hang on a second. I did my own testing in Release builds. The problem comes in when the CLR has to search up the call chain to find a handler. It's not so much the Throw that's slow, as it is finding a Catch.
|
|
|
|
|
I'm for avoiding try/catch blocks unless absolutely necessary. It's a heavy operation and should be avoided if you can solve it by using normal means of handling it.
eg. check if the file exists before performing any operation on it (open, write, read) instead of just trying to open/write/read it and catching the exception.
Just my thought.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
