n-tier input and exceptions

[headware]

I realize that when making a web application, performing input
validation in the browser is good because it prevents postbacks.
However, input checking that goes beyond making sure a value exists or
that it's not alphabetic when it's supposed to be numeric is arguably
best left to the business tier code on the server where there is
access to other data.

My questions, is what's the best way to communicate complicated error
checking failures? I was thinking that it would be to throw exceptions
from the business tier to the GUI tier. However, I'm reading that
maybe that's not the right way to go. Most people feel that exceptions
are slow and should only be used in situations in which the program
could be relatively easily tripped up by forces outside of its control
(like when trying to access a file that the user might have deleted).

So if exceptions are not a good way to go, what's the best way to move
input validation errors between the business and presentation tiers?
How about simply creating and object containing a list of error
messages and have the GUI display them? That's essentially what I was
thinking the exceptions would do.

Dave

[Joerg Jooss]

headware wrote:

I realize that when making a web application, performing input
validation in the browser is good because it prevents postbacks.
However, input checking that goes beyond making sure a value exists or
that it's not alphabetic when it's supposed to be numeric is arguably
best left to the business tier code on the server where there is
access to other data.

My questions, is what's the best way to communicate complicated error
checking failures? I was thinking that it would be to throw exceptions
from the business tier to the GUI tier. However, I'm reading that
maybe that's not the right way to go. Most people feel that exceptions
are slow and should only be used in situations in which the program
could be relatively easily tripped up by forces outside of its control
(like when trying to access a file that the user might have deleted).
A failed precondition for a business component is no less exceptional to me
than some technical issue like a file not found error -- it's not
recoverable and must be reported back to the user.

Using an error object also implies using return values or out/ref parameters
in all business methods. That means explicit checking is required -- which
is the exact reason not to communicate errors in this fashion in the first
place, because it can be ignored (see Win32 ;->).

And as far as performance is concerned... I'd go with a clean design first
before falling for potential myths regarding performance.
So if exceptions are not a good way to go, what's the best way to move
input validation errors between the business and presentation tiers?

I don't see anything wrong with your approach if it's applied to UI layer
(actually, no web framework I'm aware of handles validation errors at UI
level by exceptions). Validation at this level is required anyway, as there
are potentially different validation rules at UI level than at BC level
(data entered on Web forms is text -- data processed by buisness components
should be the "true" data type like dates).

Cheers,

--
Joerg Jooss
www.joergjooss.de
ne**@joergjooss.de

[headware]

Joerg,

I appreciate the reply and you make some good points, especially
regarding the fact that if I don't use exceptions, the only time the
errors will be caught is when people bother to look for them in the
GUI tier. That alone seems to make the use of exceptions the right
option. Which makes me wonder why I don't hear about exceptions being
used in this way more.

Does anyone else have any input on this?

Dave

"Joerg Jooss" <jo*********@gmx.net> wrote in message news:<uS**************@TK2MSFTNGP10.phx.gbl>...

headware wrote:

I realize that when making a web application, performing input
validation in the browser is good because it prevents postbacks.
However, input checking that goes beyond making sure a value exists or
that it's not alphabetic when it's supposed to be numeric is arguably
best left to the business tier code on the server where there is
access to other data.

My questions, is what's the best way to communicate complicated error
checking failures? I was thinking that it would be to throw exceptions
from the business tier to the GUI tier. However, I'm reading that
maybe that's not the right way to go. Most people feel that exceptions
are slow and should only be used in situations in which the program
could be relatively easily tripped up by forces outside of its control
(like when trying to access a file that the user might have deleted).

A failed precondition for a business component is no less exceptional to me
than some technical issue like a file not found error -- it's not
recoverable and must be reported back to the user.

Using an error object also implies using return values or out/ref parameters
in all business methods. That means explicit checking is required -- which
is the exact reason not to communicate errors in this fashion in the first
place, because it can be ignored (see Win32 ;->).

And as far as performance is concerned... I'd go with a clean design first
before falling for potential myths regarding performance.

So if exceptions are not a good way to go, what's the best way to move
input validation errors between the business and presentation tiers?

I don't see anything wrong with your approach if it's applied to UI layer
(actually, no web framework I'm aware of handles validation errors at UI
level by exceptions). Validation at this level is required anyway, as there
are potentially different validation rules at UI level than at BC level
(data entered on Web forms is text -- data processed by buisness components
should be the "true" data type like dates).

Cheers,