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).

> 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?

"Joerg Jooss" <joerg.jooss@gmx.net> wrote in message news:<uStxfo3wEHA.3976@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).
>