Hi,

I have a method that returns a dataset to the client. There will be times
when the method should not return a dataset because it would violate a
business rule. The issue I have is that I need to return the type of business
rule violation to the client. I can throw a business rule exception (create a
custom business rule exception) which would include a message that the client
can catch and display. However, I am under the impression that exceptions are
"expensive" (extra processing) and that they should be reserved for truly
exceptional cases, which a business rule violation is not. the only other
thing I could think of is to also have an out parameter that could represent
the business rule violation (as a string, numeric code, collection or
whatever). That way, the client can check to parameter to see if it has a
business rule violation, and if it does, it could get the business rule
violation error from the parameter (by reading directly or looking up a
code). I have not seen this solution written up anywhere and would like some
feedback as to whether this would be good practice. As for the dataset, I
could just return null which hopefully the client would not attempt to use
anyway if there were business rule errors.


Thanks.

Hi Robinne123,

Welcome to MSDN newsgroup.
As for the returning business rule validation result from business
components to client caller, I think you're right that using exceptions
will be expensive in such scenario, and exceptions are mainly used for
application code logic errors....

Also, as for using basic types, I'd prefer using integer value to
indicate different processing result since it'll cause least performance
overhead. And one example on this is just the COM component's HRESULT
which is a 32 bit integer that contains the method processing result and
error info..... Also, if you need to displaying some human readable
error info at client caller side, you can consider maintaing a error
message lookup table in memory to map the integer error code to string
message....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


--------------------

2 cents from a .NET newbie:

First of all exceptions are not as expensive as you might think. In the
Win32 world I could have told you exceptions use almost no extra resource
UNLESS an exception is thrown, and I'm almost certain this holds true for
..NET too. Also in the case an exception is thrown, it's really not that
expensive. There's a "yoda" page on the topic (no, I do not have the link -
but you can dig it up).

In your case I think an exception is a good mechanism for handling this
business-rule errors because:

1) Exceptions are exceptions, not catastrophic errors. Don't reserve them
for cases where an error-code is not feasible, use them judiciously in other
places too.
2) Your business logic exception will most likely result in an interaction
with the user (showing an error message). Compare the time your monitor
takes to REFRESH it's image to the time it takes for an exception to
propagate over a very deep stack frame (and you probably don't have a very
deep stack frame); I bet you can have a few millions exceptions before the
screen manages to refresh itself :-)
3) Using exceptions helps stream-line your code by NOT testing for an error
message every other line of code; You may simply assume everything works
just fine and have just one exception-handling code in the procedure that
initiates the call. I assume this would be a button-click event or something
similar.
4) Exceptions will also stream-line business-logic code because of the same
raison: you can assume everything works fine and, if at step N you find an
error, you simply raise an exceptions and be done with it: no messing-around
with error codes and getting out of deep loops.

You may simply run a few tests and see for yourself how expensive exceptions
are, but do not test the time-cost of exceptions within the IDE! I think the
IDE has it's hooks on your code and, when an exceptions is thrown it's the
first to have it's say about it (at least that's how it used to be in the
good-old Win32). Forgetting about this Win32 parallel, please take a look at
the "yoda" page I mentioned above, that's where I took my hint about NOT
testing exception-times within the IDE :-)

"Robin" <robinne123 (AT) newsgroups (DOT) nospam> wrote

Steven Cheng[MSFT] <stcheng (AT) online (DOT) microsoft.com> wrote:
How expensive do you think exceptions actually are? How many business
rule violations do you think the OP is likely to see? I suggest that
unless this is a very unusual situation, exceptions will perform
perfectly adequately, and will be a lot easier to use in terms of
ensuring that the validation is not just ignored.

At the very least an Enum should be used. Unless we actually have some
concrete evidence that the performance of just this little bit is a
bottleneck, I'd be much more concerned about an elegant solution than
performance at this stage.

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Robin <robinne123 (AT) newsgroups (DOT) nospam> wrote:
I suggest you have some sort of "Is this valid?" method which returns
true or false, and make the method which is meant to actually "do"
something throw an exception on error. It's unlikely that the exception
will cause a significant performance problem unless you are getting
thousands and thousands of these in a second - in which case I suggest
the problem should be fixed higher up. (You shouldn't be violating
business rules that often!)

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Cosmin Prund <cosminREMOVE (AT) adicomsft (DOT) NOSPAM.ro> wrote:
http://www.pobox.com/~skeet/csharp/exceptions.html

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too