Brendan Tompkins [MVP]

"Never use exceptions for application logic or flow control" does not mean to use return codes, which the post you link to suggests. I responded to your post here (http://dotnetjunkies.com/WebLog/darrell.norton/archive/2004/08/25/23249.aspx).

Okay, so I've always thought that returning an int to indicate success/failure was cheesy. The thing that is attractive about using exceptions, is that you can be more expressive about what happened. But then again, using an exception for normal conditions seems to be forcing a round peg into a square hole.

IMO, Status codes are great if your status can be boiled down to true or false. (public bool AttemptSomething()) If you need to be more expressive that, what works best? If the error condition is expected, how do you notify your caller? Returning an more complex object of some type? Is this just a design issue, and by that I mean with good design this isn't needed?

It depends. Basically your method should do what its name indicates it will do. If it cannot, then it throws an exception. But your method should be able to do what it says it will do most of the time. :)

If the error condition is likely to happen, such as attempting to gain a thread lock, then you should name your method TryAcquireLock, for example. This is the naming convention that v2 of the Framework is implementing. Methods named like this can return a bool to indicate true (we got the lock) or false if not. You would not want to try that method often if the chance of failure was 50% or so, your perf would die.

So I would say I agree with your comment. :) If it gets much more complex, then custom business objects need to be created or extended to handle the more complex error handling. All of this is, of course, my humble opinion.

Correction: "You would not want to try that method often USING EXCEPTIONS if the chance of failure was 50% or so, your perf would die."

This is good stuff. Thanks Darrell.

We all try to help each other out as best we can! :)

Today, I ran into a situation where I needed to validate a business rule within a business object. ...

Today, I ran into a situation where I needed to validate a business rule within a business object. ...

Today, I ran into a situation where I needed to validate a
business rule within a business object. ...

Today, I ran into a situation where I needed to validate some
Business Rules (BRs) within a business...