Exception or validation method?

[Andy]

Hi all,

This is more of a design question. I'm building an n-tier application,
and the question revolves around the buisness layer telling the
application that a value is not appropriate for whatever reason.

What is the recommended way of doing this?

Thrown an exception of a property is assigned a bad value? Throw an
exception when a method is called that needs to use that value? Create
a method that will indicate via a return code if the data is valid (and
if thats how to do things, how do you tell the application which value
is incorrect)?

What if for one application you need to validate the field as soon as
the user tries to move to the next field, and another (like an asp.net
page) you valid the record when save is click?

Thanks for any suggestions!
Andy

 

[Howard Swope]

Hi Andy:

This is always a sticky issue, but I think that you need to validate as soon
as you possibly can. If you have a user interface element that receives
input and you always know what the bounds of that input are, the user should
not be able to leave the interface element with improper data. However, if
your interface is more general and may apply in multiple input situations
where the bounds of the input are not known until the input is moved to the
next component in line (like business logic), you might wait to validate a
whole group of data at once and return to the user with a report. This would
make sense if other factors come in to play, like balancing immediate
validation vs. the cost of a trip across the network. Unless you are dealing
in a situation where a system is unattended by a user or it is only checked
periodically, I would not validate data by having its use cause a failure.
It's just one more thing to go wrong.

 

[Andy]

Thanks Howard, your answer does make sense.

So to be clear from the last few lines, you think that the objects
should expose some method that will check the data and return data
indicating what ones are valid, and not throw an exception?

Something else comes to mind..

Whats your opinion on when an exception is thrown in say the data
layer?

I would think that as each layer catches an exception, it would wrap it
in a general exception (or more specific one, if need be) and rethrow
that.

My thinking is that if the application should ONLY know about the
business layer, it should only get exceptions defined in that layer
(althought inner exceptions would be from lower layers). So that the
business layer should throw a new exception, with the data layer
exception as an inner exception.

Any thoughts around that?

Thanks!
Andy

 

[Nicholas Paldino [.NET/C# MVP]]

Andy,

The way I think of it is like this. Exceptions are for exceptional
cases, and business logic is not one of those cases. Also, because the
frequency of incorrect data being entered is high compared to other
exceptional cases, you can run into a performance issue (since
throwing/catching an exception is much slower than checking a value, for
instance).

Business logic is just validation and operations. An exception should
be thrown IMO only when there is a condition or situation that is unexpected
which isn't planned for. Someone entering the wrong value somewhere isn't
one of those cases.

Hope this helps.

 

[Guest]

yeah, but I hate it when all my methods now have to have some error code as
return value, and I'd have to map the value to find out what caused it.
feels so antiquated.

maybe they need something in between, something not quite as heavy as
exceptions but still has the throw-catch paradigm. I just find it much more
convenient to deal with errors this way.

Andy,

The way I think of it is like this. Exceptions are for exceptional
cases, and business logic is not one of those cases. Also, because the
frequency of incorrect data being entered is high compared to other
exceptional cases, you can run into a performance issue (since
throwing/catching an exception is much slower than checking a value, for
instance).

Business logic is just validation and operations. An exception should
be thrown IMO only when there is a condition or situation that is unexpected
which isn't planned for. Someone entering the wrong value somewhere isn't
one of those cases.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi all,

This is more of a design question. I'm building an n-tier application,
and the question revolves around the buisness layer telling the
application that a value is not appropriate for whatever reason.

What is the recommended way of doing this?

Thrown an exception of a property is assigned a bad value? Throw an
exception when a method is called that needs to use that value? Create
a method that will indicate via a return code if the data is valid (and
if thats how to do things, how do you tell the application which value
is incorrect)?

What if for one application you need to validate the field as soon as
the user tries to move to the next field, and another (like an asp.net
page) you valid the record when save is click?

Thanks for any suggestions!
Andy

 

[Chad Z. Hower aka Kudzu]

yeah, but I hate it when all my methods now have to have some error
code as return value, and I'd have to map the value to find out what
caused it. feels so antiquated.

maybe they need something in between, something not quite as heavy as
exceptions but still has the throw-catch paradigm. I just find it
much more convenient to deal with errors this way.

It all depends on your paradigm. Exceptions are not always errors and are very valid returns for
validation errors, especially when process boundaries are crossed. Take a look at various FCL
Parse etc, and these dont even cross process boundaries.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

 

[Jon Skeet [C# MVP]]

The way I think of it is like this. Exceptions are for exceptional
cases, and business logic is not one of those cases. Also, because the
frequency of incorrect data being entered is high compared to other
exceptional cases, you can run into a performance issue (since
throwing/catching an exception is much slower than checking a value, for
instance).

The performance is *very* unlikely to be significantly affected by
throwing an exception. Even if you were to throw 100,000 exceptions in
an hour (which would be very unlikely, IMO) that would still only take
up a tiny proportion of the processing power of any server which is
likely to handle that many requests.

(If it were *so* crucial not to throw exceptions, ASP.NET no doubt
wouldn't do so when HttpResponse.Redirect is called...)

Personally I like exceptions in terms of their fail-fast nature -
they're a good way of making it very hard to ignore the problem. It's
all too easy to ignore return values (just look at the number of people
who have bugs due to neglecting the return value of Stream.Read).

Business logic is just validation and operations. An exception should
be thrown IMO only when there is a condition or situation that is unexpected
which isn't planned for. Someone entering the wrong value somewhere isn't
one of those cases.

I think it really depends on the situation. Personally I like to
provide two methods, one of which will throw an exception and one of
doesn't. That way in the (IME) rare situation where you're likely to be
validating hundreds of thousands of entries without doing much else,
you can avoid the performance hit of exceptions, and likewise when you
don't want the "fail fast" behaviour.

 

[Howard Swope]

Thanks Howard, your answer does make sense.

So to be clear from the last few lines, you think that the objects
should expose some method that will check the data and return data
indicating what ones are valid, and not throw an exception?

I think a multi-tiered system should be checking on if the data is valid as
soon as it can.

I think throwing an exception vs indicating validity depends on the data.
For example in a system I am working on a user can organize a subset of data
into groupings. The original data may change and then the groupings may no
longer be valid. In this case I want the user to see an indication of the
validity of their groupings and be able to doctor them according to the new
base data. It is important to indicate validity in this case. The system is
designed with this in mind. No exception is thrown if a user opens his
grouping in the system, but validity is indicated. If for example, a value
of 101 is entered where a percentage is expected then I would throw an
exception.

*** An important thing to consider too, is if you throw an exception,
execution will pick up at the exception handler. You might encounter an
instance where this is not the desired outcome. You might want to inform the
user through a modal dialog that an error has occurred and then continue on
in your code handling the error condition.

Something else comes to mind..

Whats your opinion on when an exception is thrown in say the data
layer?

As long as it is consistent and well documented I don't have a problem with
it. Consistent exception handling has been one of the greatest joys of my
..Net experience.

I would think that as each layer catches an exception, it would wrap it
in a general exception (or more specific one, if need be) and rethrow
that.

My thinking is that if the application should ONLY know about the
business layer, it should only get exceptions defined in that layer
(althought inner exceptions would be from lower layers). So that the
business layer should throw a new exception, with the data layer
exception as an inner exception.

Any thoughts around that?

I think that the end user should never see an error message that is not
based in the domain of the application. However, they still need to be able
to alert technical support as to the nature of the error they receive in
some way. This also holds true for a programmer that receives an exception
from a subsystem. He should recieve information from the subsystem he was
addressing but also needs to address or pass on the root cause of the error
so that it can eventually be resolved. I still think that there is a little
area to fudge this amongst the developers, as long as the end user isn't
confronted with some error like:

Unhandled exception at 0xABCD1234, deleteing all your work. ;-)